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Abstract 



o 

Q, 

I Linearisability has become the standard safety criterion for concurrent data structures ensuring 

. that the effect of a concrete operation takes place after the execution some atomic statement (often 

referred to as the linearisation point). Identification of linearisation points is a non-trivial task and 
, it is even possible for an operation to be linearised by the execution of other concurrent operations. 

' This paper presents a method for verifying linearisability that does not require identification of 

l_J ' linearisation points in the concrete code. Instead, we show that the concrete program is a refinement 

^ , of some coarse-grained abstraction. The linearisation points in the abstraction are straightforward 

^ ' to identify and the linearisability proof itself is simpler due to the coarse granularity of its atomic 

statements. The concrete fine-grained program is a refinement of the coarse-grained program, and 
hence is also linearisable because every behaviour of the concrete program is a possible behaviour its 
abstraction. 



1 Introduction 



With the increasing prevalence of concurrent computation in modern systems, development of concurrent 
data structures that enable a greater degree of parallelism have become increasingly important. To im- 
' prove efficiency, programs that implement concurrent data structures often exhibit fine-grained atomicity 

and use atomic non-blocking compare-and-swap operations as their main synchronisation primitive. A 
consequence of these features is the increase in complexity of the programs, making their correctness 
. ^ harder to judge. Hence, formal verification of programs for concurrent data structures is known to be a 

r> ' necessity. There are even examples of errors being uncovered by formal verification in published algorithm 

I that were previously believed to be correct [14] . 

The main correctness criterion for programs that implement concurrent data structures is linearis- 
ability [30) . which allows one to view operations on concurrent objects as though they occur in some 
sequential order. Over the years, numerous approaches to verifying linearisability have been developed 
using a variety of different frameworks, and several of these approaches are partially/fully mechanised. 
Herlihy and Wing's original paper use the notion of a possibilities mapping, which defines the set of 
possible abstract data structures that corresponds to each point of interleaving. Doherty et al [5l [15] use 
a simulation-based method using input /output automata with proofs mechanised using PVS. Vafeiadis et 
al use a framework that combines separation logic and rely /guarantee reasoning |461 148] . An automated 
method based on this theory has been developed, but the method is known not to apply to a more com- 
plex programs [17] • Derrick et al have developed refinement-based methods that have been mechanised 
using the theorem prove KIV [TTl [121 [IS]- Turon and Wand propose a compositional rely/guarantee 
framework with separation logic to show that the concrete programs implement another so-called "obvi- 
ously correct" program, which may or may not be linearisable [45| . Several other verification methods 
have been proposed which we discuss in more detail in Section [HI 

Each of the existing methods above build on the fact that linearisability guarantees the existence 
of a so-called linearisation point, which is an atomic statement whose execution causes the effect of an 
operation to be felt. 
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"Linearisability provides the illusion that each operation applied by concurrent processes takes 
effect instantaneously at some point between its invocation and its response." (30j 

Hence, the methods in [Sj [TTJ [121 HSl HH |46l |47l [48] involve identification of linearisation points in the 
concrete code, and a proof that execution of a linearisation point does indeed correspond to an execution 
of the corresponding abstract operation. However, in many sophisticated programs, the linearisation 
points are not always immediately identifiable, and often require a high degree of expertise on the proof 
techniques as well as the program at hand. In more complex algorithms, it is even possible for some 
operations to be linearised by the execution of other concurrent operations and hence require the use 
backwards reasoning techniques O [TTJ [131 ESI HSl [48] . Algorithms that require backwards reasoning are 
precisely those that cause difficulties for the method described in |47j . 

We present a method for verifying linearisability where we aim to establish a relationship between a 
fine-grained concrete program and a program in which the operations execute with coarse-grained atomic- 
ity. In particular, the fine-grained program is one that implements the one with coarse-grained atomicity. 
Groves [2^ and separately Elmas et al [25] start with a coarse-grained program, which is incrementally 
refined to an implementation with finer-grained atomicity. Splitting the atomicity of a statement is jus- 
tified using reduction |33| . which ensures that the operations are immune to interleavings with other 
concurrent statements. However, because one must consider each pair of interleavings, reduction-based 
methods are not compositional, and hence do not scale well as the complexity of an operation increases. 

We develop a framework that enables reasoning over the interval time in which a program executes, 
presenting an alternative to traditional reasoning over the pre/post states of a program and captures the 
possible interference that may occur during a program's execution |18j . Our model incorporates fractional 
permissions |3] to simplify reasoning about conflicting accesses to shared variables [TS]. Permissions are 
also used to model properties such as interference freedom and locality. Our framework also incorporates 
reasoning about pointer-based programs by allowing the domains of each state is assumed to consist of 
variables and addresses, and take extra care when updating or evaluating pointers because the values at 
their addresses may be dynamically changing. The behaviour of a command is defined over an interval, 
and hence, for example, expression evaluation is assumed to take a number of steps. Note though that 
we do not take into account all the complexities of non-deterministic expression evaluation |28| . 

We develop interval-based theories refinement, namely behaviour refinement (which is akin to opera- 
tion refinement) and data refinement (which allows the state spaces of two programs to be linked using a 
simulation predicate). As far as we are aware, our formulation of data refinement over intervals is novel 
to this paper. Data refinement is used to link the abstract representation of the data structure (in which 
each operation takes place in a single atomic step) and the coarse-grained abstraction (in which operations 
execute on the same data representation as the implementation, but with a coarse-grained atomicity). 
Like Derrick et al [42l [TS] [12] , the data refinement proof encapsulates a proof that the coarse-grained 
program is linearisable with respect to the abstract representation. Then to show that the final imple- 
mentation is linearisable, we show that the it is a behaviour refinement of the coarse-grained abstraction. 
We use Treiber's Stack [44] to illustrate our approach. 

Interval-based methods for proving linearisability have also been proposed by Baumlcr et al [5] . How- 
ever, their model assumes that a program executes with its environment by interleaving the statements 
of a program with those of its environment, as opposed to our model, that allows true concurrency, which 
allows one to model the inherent true parallelism in modern many/multicore systems. Furthermore, 
Baumler et al prove linearisability of the concrete program directly unlike our method in which we first 
show that the fine-grained (concrete) implementation refines a coarse-grained abstraction. Due to the 
coarse-granularity of the statements in the second program, its linearisation points are straightforward 
to identify, and the linearisation proof itself is simpler. 

This paper is structured as follows. In Section [21 we present a formalisation of linearisability and 
an alternative definition that simplifies its proof. In Section [3] we present the Treiber stack, which we 
use as a running example throughout the paper. We present our interval-based framework in Section 21 
and use it to define a semantics for a language that allows explicit control of a program's atomicity 
(Section [5]). We also develop a theory for refining the behaviour of commands within this framework. In 
Section [6l we develop the coarse-grained abstraction of the Treiber stack, present methods of verifying 
its linearisability using data refinement, and present the actual proof of its correctness. As part of 
this, we develop data refinement rules for our interval-based framework. We then develop methods for 
showing that a fine-grained program implements a coarse-grained abstraction. To this end, we develop 
compositional rely/guarantee-style rules in Section [T] and some high-level transformation rules specific to 
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CAS-based implementations in Section 17.31 We apply these to prove that the Treiber stack implements 
the coarse-grained abstraction in Section |8l 

2 Linearisability 

In this section, we present the original definition of linearisability [30] and an alternative definition that 
simplifies proofs of linearisability. 

Two operations opi and opj of a concurrent program are said to execute concurrently iff the invocation 
of opi occurs after the invocation but before the response of opj. During a concurrent execution of two or 
more operations, the atomic statements of the operations may be arbitrarily interleaved. As a result, the 
effect of two concurrent operations may take place in any order and does not correspond to the ordering 
of invocations and responses. For example. Fig. [T] depicts a scenario where process r linearises before 
process p even though the invocation of p occurs before the invocation of r. Similarly, process q linearises 
after process q even though the response of process q occurs before the response of process p. 

Not every ordering of invocations and responses is linearisable. In particular, linearisability requires 
that a chosen ordering of effects of the concurrent operations corresponds to a valid sequential history. 
For example, assuming that we start with an empty stack, history in Fig. [1] is linearisable whereas Fig. [5] 
is not |12] . In particular, history Fig. [T] can be linearised by selecting linearisation points marked by the 
crosses. In contrast, there is no possible selection of linearisation points for Fig. [2] that results in a valid 
sequential history because processes q and r both return a;, even though there is only one concurrent 
push(x) operation and execution started with an empty stack. We give a more formal presentation of 
these concepts in Example 12.21 

2.1 Herlihy and Wing's definition 

To formalise linearisability using the nomenclature of Herlihy and Wing [30], we let seq.X denote se- 
quences of type X . We assume sequences start with index 0. An event is a tuple Event = Op x Proc x 
{invoke^ return} x seq. Val, respectively corresponding to an operation identifier, a process identifier, the 
type of the event (invoke or return), and a sequence corresponding to the input /output parameters of the 
event. We use opp{ki, k2, . . . kn) and opp {ki, fc2, . . . A;„) to denote operations {op,p, invoke, (fci, . . . , A;„)) 
and {op, p, response, {ki, kn)), respectively. Notations op^ and op^ denote an invoke and response 
events with no parameters, respectively. A history is a sequence of invocation of response events. 

Example 2.1. For a stack data structure, sequences ([1]) and ([2]) below are possible histories of invocation 
and response events, where p, q and r are pairwise distinct processes. 

{pushup {x),pushlj{y),pop'^,push^-, push j^,pop^ (Empty)) (1) 
{pushup {x),pop'g,popl, pop j^{x), push^ , pop^ ( x ) ) ( 2 ) 

A visualisation of histories ([T} and ([2]) are given in Fig. [T] and Fig. [2l respectively. ^ 

For H G scq.Event of invocations and responses, H \ p denotes the subsequence of H consisting of 
all invocations and responses of process p. Two histories Hi, H2 are equivalent if for all processes p, 
Hi \ p = \ p. An invocation opip{x) matches a response opj^{y) iff opi = opj and p = q. An 
invocation is pending in a history H iff there is no matching response to the invocation in H . We let 
complete(H) denote the maximal subsequence of history H consisting of all invocations and matching 
responses in H , i.e., the history obtained by removing all pending invocations of H . 

An operation op in a history is defined by an invocation invocation. op followed by the next matching 
response response. op. For a history H , <h is an irreflexive partial order on operations where opi <h opj 
iff response. opi occurs before invocation. opj in H, i.e., opi and opj do not execute concurrently and opi 
occurs before opj. 

Definition 2.1 (Sequential history). A history H is sequential iff the first element of H is an invocation 
and each invocation (except possibly the last) is immediately followed by its matching response. 

Definition 2.2 (Linearisability [SO]). A (concurrent) history HC is linearisable iff HC can be extended 
to a (concurrent) history HC by adding zero or more matching responses to pending invocations such 
that complete{HC') is equivalent to some sequential history HS and <hc Q <hs ■ 
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push'pix) pushf pushlix) push^' 

I X 1 I 1 

pushliy) pushf pop^ popf{x) 

I XH I 1 

pop'^ pop^{Empty) pop^ pop^{x) 

I — X 1 I 1 

Figure 1: History corresponding to ([1]) Figure 2: History corresponding to ([2]) 



Example 2.2. Using Definition 12.21 assuming that the stack is initially empty, history ([T]) is may be 

linearised by the following sequential history: 

{pop' , pop^ {Empty), push'^ {y) , pushf , pushp {x), push^) (3) 

Note that a single concurrent history may be linearised by several sequential histories. For example ([1]) 
can also be linearised by the following sequential history, in which case the order of the linearisation 
points of process p and q shown in Fig. [T] would be swapped. 

{p0Pr,P0Pr {Empty), pushp {x) , push^^ , push^ {y) , pushf) (4) 

Linearising history ([1]) using ([3]) results in a final stack {y,x) with element y at the top, whereas (|4]) 
results in a final stack {x, y) with element x at the top. 

Unlike ([1]) , there is no valid linearisation of ([U . ^ 

The definition of linearisability allows histories to be extended with matching responses to pending 
invocations. This is necesssary because some operations may be past their linearisation point, but not 
yet responded. For example consider the following stack history, where the stack is initially empty. 

{pushp{x),pop'g,popf{x)) (5) 

The effect of the invocation pushp{x) has clearly been felt in ([5|) because the popq returns x, i.e., the 
linearisation point of pushp{x) occurs before that of pop^j. We can validate this formally because ([5]) can 
be extended with a matching response to pushp{x), then linearised by the following sequential history 

{pushp {x), push^ , popg ,pop^{x)) 

2.2 An alternative definition of linearisability 

Verifying linearisability (Definition [221) by reasoning at the level of histories of invocations and responses 
directly is clearly infeasible. Hence, we follow the methods of Derrick et al who link the concurrent and 
sequential histories using a matching function j42[[T^[T5] . This then allows one to prove linearisability via 
data refinement. The key idea here is to distinguish between invocations that have and have not linearised 
but not yet returned. This allows one to determine whether or not a concrete program contributes to the 
abstract history. 

One must first define matching pairs of events and pending invocation events within a sequence of 
events. 

Definition 2.3 (Matching pair, Pending invocation). For a sequence of events H , we say i,i G dom.H 

forms a matching pair in H iff mp}j{i,i) holds and i is a pending invocation in H iff pendingn -i holds, 
where 

mpH-{i,j) = (i < j) A {H .i.opid = H .j.opid) A {H .i.proc — H .j.proc) A 
{H.i.type = invoke) A {H.j.type ~ response) 
(Vfc • i < k < j =^ H .k.proc ^ H .i.proc) 

pendingn .i ^ {H.i.type ~ invoke) A (Vj: doni.i/ • j >i^ -impn .{i, j)) 

Hence, two indices i and j form a matching pair in a sequence of events H iff j follows i, events H .i, 
H .j are invocations and responses of the same operation by the same process and there are not other 
invocations/responses by process H. i.proc between i and j. Index i of sequence H is pending if there is 
no matching index j > i. 
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Example 2.3. Given that H is the history corresponding to ([T]), mpff.(0,4), mp//.(l,3) and mpH-i^jb) 
hold. If h is the history corresponding to mph.{l,2) and pendingh-O hold. ^ 

Using these, one may now define the set of legal histories. 

Definition 2.4 (Legal history). A history H is legal iff legal. H holds, where 

legal. H = Vi: dom.H • '\f{H .i.type ~ invoke) then {pendingn .i V 3j:dom./f • mpH.{i,i)) 

else (3j:doni._ff • mpH-{j, i)) 

Hence, H is legal iff for every index corresponding to an invocation in H is cither pending or has a 
matching index, and indices corresponding to responses have an earlier matching invocation. Using this, 
one may now define a notion of a lin-relation between two histories. 

Definition 2.5 (Lin-relation). A history HC is said to be in a lin-relation with history HS with respect 



to a matching function / iff linrel{HC,f, HS) holds, where 

linrel{HCJ, HS) = / G dom.HC ^ dom.HS A (6) 

(Vi, j:dom.77C • mpnc-ihi) =^ {hj} ^ dom./) A (7) 

(Vz: dom.HS • HC.i = HS.{f.i)) A (8) 

(Vz, j:dom.77C • Kj A mpHc-ihj) f-j = ,/•« + 1) A (9) 



{\fi,j,k,l:dom.HC • j <k A mpHC-ihj) A mpnc-ikj) ^ f -j <f-k) (10) 

Hence, a concrete history HC is in a lin-relation with sequential history HS with respect to linearising 
function / iff / is a surjection (an onto function) mapping the indices of HC to the indices of HS ([5]), 
every pair of indices of HC that forms a matching pair in HC is in the domain of / ([7]) , for every index i 
of the sequential history HC, element HC.i is the same as element HS.{f.i) (O, for every matching pair 
of indices i and j, f.j is one greater than f.i ([5]), and matching indices i, j must occur before matching 
indices k, I ii j occurs before k pO)) . 

We let prefix. tt denote the set of all prefixes of a sequence tt and hence ss G prefix. tt denotes that 
sequence ss is a prefix of tt. Using the definitions above, we now present Derrick et al's alternative 
definition of linearisability [12] • 

Definition 2.6 (Linearisability). A (concurrent) history HC is linearisable with respect to a sequential 
history HS iff linearisable{HC , HS) holds, where 

lmeansable{HC , HS) = 3HE: seq.Event • HC e prefix. HE A legal. HE A 3f • lmrel{HEJ, HS) 

Hence, concrete history HC is linearisable with respect to sequential history HS iff HC can be extended 
to a sequence of (return) events HE such that the exendcd history HE is legal and there exists a linearising 
function between HE and HS . 

3 Example: The Treiber Stack 

We present our methods via a verification of the Treiber Stack as a running example (see Fig. [3]), which 
is a well-known program that implements a list-based concurrent stack |44j . Verification of this stack has 
become a standard exercise in the literature. The program uses a pointer Top of type ptr_ctr within 
which the pointer field ptr stores a pointer to the top of the stack and counter field ctr stores the number 
of times Top has been modified. Stack nodes have a field key for the value of the node and a next field 
nxt, which is a pointer to the next node of the stack. 

Like many lock-free algorithms, the stack is implemented using an atomic non-blocking compare-and- 
swap CAS{ae,a, /3) primitive, which takes an address-valued expression ae and variables a and /3 as 
input. If the value at ae is equal to a, the CAS updates the value at ae to /3 and returns true, otherwise 
(the value at ae is not equal to a) the CAS does not modify anything and returns false. 

The stack processes may perform either execute a push push(x) or a pop operation pop. Within 
operation push(x), the executing process uses local variables n and t. The process executing push(x) sets 
up a new node with value x (lines /ii-/i2), then executes a try-CAS loop (lines h^-h^), where the value 
of global variable Top is read and stored in local variable t (line /13), n.nxt is set to be the local t (line 
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data node {key:Val; iixt:*node} 
struct ptr_ctr {ptr: H<node; ctr:nat} 
var Top: H<ptr_ctr 
initially Top = (null, 0) 



pusli(x) = 

hi: n ;= new(Node) ; 
/12: n.key := x ; 



pop ^ 



repeat 

li: t := *Top ; 
I2: if t.ptr — null then 
Z3: rv := Empty ; 
I4: return 



repeat 

/13: t := *Top ; 

/14: n.nxt := t.ptr 

/15: until CAS(Top,t, (n, t.ctr + 1)) 



else 

I5: tn := t.ptr — ^ nxt ; 
/g: rv := t.ptr — > key 



fi; 

k: until CAS(Top,t, (tn, t.ctr + 1)) ; 
fe: return rv 



Figure 3: Push and pop operations of Treiber's lock-free stack 



hi) and a CAS(Top,t, (n, t.ctr + 1)) is executed (line /15). The loop terminates if the CAS is successful, 
otherwise lines /13-/15 are re-executed. Operation pop stores Top in local variable t (line h). If t is null 
(line I2) it returns empty (line I3), otherwise it stores the value of t.ptr nxt in local variable tn (line 4) 
and the value of t.ptr key in local variable rv (line l^). The loop terminates if the CAS is successful 
(line Iq), otherwise it re-executes the loop body (i.e., from line li). 

We verify this algorithm for an arbitrarily chosen set of processes P as follows, assuming that AS{P), 
LS{P), and TS{P) denote, respectively, the abstract stack (which is implemented as a sequence), the 
coarse-grained abstraction (which is implemented as a linked list) and the fine-grained concrete imple- 
mentation (i.e., the Treiber Stack). The approach we propose is to show that TS{P) implements (i.e., is a 
refinement of) LS{P), which itself implements AS{P). Furthermore, we show that LS{P) is linearisable 
with respect to AS{P) [30l [H SHI |46] . 

The idea is that the coarse-grained abstraction LS{P) allows concurrency, but large parts of the code 
are sequential. This simplifies the proof of linearisability because a data refinement is performed from 
an abstract data structure representation in AS{P) to LS(P), as opposed to a data refinement from 
AS{P) directly to the fine-grained program TS{P). The data refinement between AS{P) and LS{P) is 
performed on an extended specification that includes histories of invocations and responses |12j . which 
allows one to relate the refinement to Herlihy and Wing's original definition. Verification that TS{P) is 
a refinement of LS{P) is performed using a number of decomposition and transformation theorems. 

4 Interval- based framev^ork 

We start by presenting our programming syntax. We then present our interval-based framework, which 
has similarities to Interval Temporal Logic |37j . However, the underlying semantics consists of complete 
streams that map each time to a state, and adjoining intervals are assumed to be disjoint (adjoining 
intervals share a boundary in Interval Temporal Logic) [18| . To formalise the behaviour over an interval, 
we restrict one's view of a stream to the interval under consideration. However, because streams encode 
the complete behaviour over all time, our framework allows properties outside the given interval to be 
considered in a straightforward manner [20l [22l [18] . 

4.1 Syntax 

There are a number of well-established approaches to modelling program behaviour, e.g., Z, B. I/O 
automata. However, the use of these formalisms involve a non-trivial translation from the program to 
the model. We use a framework in which commands closely resemble program code, which simplifies the 
translation. The programs we consider often have a pointer-based structure and hence, as in separation 
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logic, we distinguish between variables and addresses in the domains of the program states [40) . 

We assume variable names are taken from the set Var, values have type Val, addresses have type 
Addr = N, Addr D Var ^ and Addr C Val. A state over a set of locations VA G Var U Addr is a 
member of StatevA VA Val (i.e., a total function from VA to Val). A state predicate over VA is a 
function of type StatevA B. 

A location may correspond to a data type with a field identifiers of type Field. We assume that every 
data type with m number of fields is assigned m contiguous blocks of memory [46| and use off set. f E N 
to return the offset of the field /. For example, for any node of the Treiber Stack, we have offset. key = 
and offset.nxt = 1. We assume that expressions have the following syntax, where k S Val is a constant, 
V S Var, ae is an address-valued expression. / is a field, e, ei and 62 are expressions, Q is a unary 
operators and © is a binary operator, respectively. Both and © are abstractions of the possible unary 
and binary operators on expressions. 

e ::— k \ v \ *ae \ ae-f \ ae f \ Qe \ Ci (B e2 

The semantics of expressions is given by hmction eval which is defined below for a state cr, where '.' 
denotes function application. 

eval. k. (7 =: k eval.{ae-f).a S eval. ae.a + offset, f 

eval. V. (7 = (T.v eval. {Qe).(T = Qeval.{e.a) 

eval.{*ae).a = a. (eval. ae.a) eval .{ei (B e2) .a = eval. (ei.a) (B eval. {e2.(T) 

Hence, the evaluation of a constant (including an address) in any state is the constant itself and an 
evaluation of a variable is the value of the variable in the given state. Evaluation of * ae returns the value 
of the state at the address that ae evaluates to, and ae-f returns the address that ae evaluates to plus 
the offset of the field /. The interpretations over unary and binary operators are lifted in the normal 
manner. We assume that expressions are well-formed so that their evaluation in every state is always 
possible. We define a shorthand 

ae ^ f = *{ae-f) 
which returns the value of the state at address ae-f . 

Definition 4.1 (Command syntax). For a state predicate c, variable w, expression e, address-valued 
expression ae, set of processes P C Proc, set of variables Z, and label I, the abstract syntax of a 
command is given by Cmd below, where C, Ci, C2, Cp G Cmd. 

Cmd Chaos | Idle \ [c] \ v := e \ ae -.^ e \ Ci ; C2 \ Ci n C2 \ 

I \\p:P Cp I {Z/Cj \ l:C \ INITC'C 

Thus, a command may be Chaos (which is chaotic and allows any behaviour), an Idle command, a 
guard [c], assignments v :— e and ae :— e, a sequential composition (Ci ; C2), a non-deterministic choice 
Ci n C2, an iteration C"^, a parallel composition W^.p Cp, a command C executing in a context Z, a 
command with a label I, or a command that executes from an initial state that satisfies c. 

As an example, consider the simple sequential program in Fig. 21 which demonstrates use of the syntax 
in Definition 14. II For the program in Fig. |4l we assume that is a sequence of values. 

Example 4.1. Operation SPush(x) updates the sequence S by appending x to the start of S, SEmpty{arv) 
models a pop operation that returns Empty, and SDoPop{arv) models a pop operation on a non-empty 
stack, which checks to see if S is non-empty, sets the return value arv to be the value of S .0, and removes 
the first element by setting the new value of S to be the tail of 5*. An single stack operation is modelled 
by SPP, which consists of a non-deterministic choice between push operations that non-deterministically 
insert one of the possible key values onto the stack, or a pop operation. A possibly infinite number of 
stack operations starting from an empty stack is modelled by SS , which ensures that variable 5" is in the 
context of the program, that the initial value of S* is (), and iterates over SPP. ^ 

As a more complicated example, we now consider the program in Fig. [SJ which is a formal model 
for the Treiber Stack from Fig. [3] We model a ptr_ctr a structure by type Ptr_Ctr = Addr x N. For 
{pp, cc) G Ptr_Ctr, we define functions ptr.{pp, cc) = pp and ctr.{pp, cc) = cc. The modification counter 
ctr.{*Top) is used to avoid the ABA problem (see Example 14. 3p . Unlike a ptr_ctr structure, which is 
assumed to be accessed atomically, list nodes are objects whose fields may be accessed independently, 
and hence the key and nxt fields are modelled as having different addresses. 
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SPush{x) = S ■.= {x)^ S 

SEmpty{arv) = [S = ()] ; arv Empty 

SDoPop{arv) = [S ^ ()] ; arv := S .0 ; S :— tail.S 

SPop{arv) = SEmpty{arv) □ SDoPop{arv) 

SPP = irix-vai SPush{x)) n SPop{arv) 

SS = (s/lNiT S^Q'SPP'^l 







Figure 4: An cibstract (sGquenticil) stack specification 


Setup{p, x) 




7 ATI/ \ 1 / 1 \ 

hi: newly ode [p, Up) ; ri2'.(np-key):~x 


TryPush[p) 




h-3- tp := *Iop ; n^: [np-nxt) ptr.tp ; njr-,: CAbrailp^lop, tp) 


DoPush[p) 




liz ■ tp * 1 op , 114: [np- nxt ) := ptr.tp ; rite,: UAoU-i\p[ lop, tp, [np, ctr.tp + i j j 


Push{p, x) 




Setup{p,x); Try Push (p)'^ ; DoPush(p) 


ToCAS{p) 




li: tp := *Top ; 1/2: [ptr.tp ^ null] ; ^5: tnp :~ ptr.tp 1—^ nxt ; Iq: rVp := ptr.tp 1— >■ key 


TryPop{p) 




ToCAS{p) ; Ih: CASFailp{Top, tp) 


Empty {p, rVp) 




h: tp := Top ; lt2: [ptr.tp = null] ; k-,: rVp Empty 


DoPop{p, rVp) 




ToCAS{p) ; Itr. CASOKp{Top, tp, {tnp, ctr.tp + 1)) 


Pop{p, rVp) 




TryPop{p)'^ ; {Empty{p, rVp) □ DoPop{p, rVp)) 


TPP{p) 




pidle:\d\e; i\~\,^,Yai Push{p, x)) r\ Pop{p, rVp) 


TInit 




*Top = {null,0) A FAddr C ^ddr\{Top} 


TS{P) 




[7op,^:4rfrfr/lNiT T/mt • H^^p |tp, Wp, top, rwp/ TFF(p)" | ] 



Figure 5: Formal model of the Treiber stack 



Example 4.2. The (interval-based) semantics of our language is given in Section lOI The behaviours of 
both CASOKp and CASFailp are given in Example 15 . 1 1 and the behaviour of newNode{p, np) is formalised 
in Example l5.2l Both commands require the use of permissions to control the atomicity (sec Section [4.5p . 

The Treiber Stack consists global address Top G Addr and a set of free addresses FAddr C Addr. The 
initial value of Top is {null, 0) and all addresses different from Top are free. We assume the existence of 
a garbage collector that gathers free pointers and returns them to FAddr. 

Execution of push(x) by process p is modelled by Push(p, x). Within the push operation, we split 
the label /15 into /1/5 and ht^ to distinguish between execution of the failed and successful branches of the 
CAS, respectively. Commands TryPush(p) and DoPush{p) model executions of the loop body that fail 
and succeed in performing the CAS at /15, respectively. Within Push{p, x), because we use an iteration, 
command TryPush{p) may be executed a finite (including zero) number of times, after which DoPush{p) 
is executed. However, it is also possible for TryPush[p) to be executed an infinite number of times in 
which case DoPush(p) never executes. Such behaviour is allowable for the Treiber Stack, which only 
guarantees lock- freedom of its concurrent processes [71 [SI [TB] . 

For the pop operation, we use ToCAS{p) to model the statements executed by process p from the 
beginning of the loop up to the CAS at Z7 (via a failed test at I2). As in Push{p, x), label I2 is split 
into 1/2 and lt2, and Ij is split into lf2 and It^ in the pop operation. The TryPop{p) and DoPop{p) 
commands model executions of the loop body that fail and succeed in executing the compare and swap 
at Z7, respectively. Command Empty{p) models an execution of the pop operation that returns empty. 
The Pop[p) operation consists of a finite or infinite iteration of TryPop{p) followed by an execution of 
either Empty(p) or DoPop{p). 

The program is modelled as a parallel composition of processes, where each process repeatedly chooses 
either a pop or push operation non-deterministically, then executes the operation. ^ 
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4.2 Intervals 

A (discrete) interval (of type Intv) is a contiguous set of integers (of type Time = Z), i.e., we define 

Intv ^ {A C Time \ Vt, t': A • Vtt: Time •t<u<t'^uG A} 

We let lub.A and gib. A denote the least upper and greatest lower bounds of an interval A, respectively, 
and define lub.0 = — cxd and glb.0 = oo. If the size of A is infinite and gib. A G Z, then lub.A = oo (i.e,. 
is not a member of Z) and if A is infinite and lub.A G Z then gib. A = — oo. The length of a non-empty 
interval A is given byi!.A = lub.A — gib. A, and we define the length of an empty interval to be £.0 = 0. 
We define the following predicates on intervals. 

Inf. A = lub.A = oo 
Fin.A = ^Inf.A 
Empty. A = A = 

Hence, Inf. A, Fin.A hold iff A has an infinite and finite least upper bound, respectively, and Empty. A 
holds iff A is empty. 

We must often reason about two adjoining intervals, i.e., intervals that immediately precede or follow 
a given interval. For A, A' e Intv, we define 

AotA' S A A' ^ ^ {\uh. A < g\h. A') A {A U A' e Intv) 

Thus, A oc A' holds if and only if A' immediately follows Aand A and A' are disjoint. Furthermore, by 
conjunct A U A' e Intv, the union of A and A' must be contiguous. Note that both A oc and oc A 
hold trivially. 

4.3 Interval predicates 

We aim to reason about the behaviours of a program over its interval of execution and hence define an 
interval-based semantics for the language in Definition 14.11 In particular, we define interval predicates 
[2H [22l [23l [T8] , which map an interval and a stream of states to a boolean. The stream describes the 
behaviour of a program over all time and an interval predicate describes the behaviour over the given 
interval. 

A stream of behaviours over VA C Var U Addr is given by the total function StreamyA = Time 
StatevAi which maps each possible time to a state over V and A. To reason about specific portions 
of a stream, we use interval predicates, which have type IntvPredyA = Ii^tv — > V Streamy^. As with 
state expressions, we assume pointwise lifting of operators on stream and interval predicates. We assume 
pointwise lifting of operators on stream and interval predicates in the normal manner, e.g., if gi and 52 
arc interval predicates, A is an interval and s is a stream, we have {gi A (72). A. s — {gi.A.s A g2-A.s). 
When reasoning about properties of programs, we would like to state that whenever a property gi holds 
over any interval A and stream s, a property 32 also holds over A and s. Hence, we define universal 
implication for gi, g2 G IntvPred as 

gi ^ 92 = VA: Intv, s: Stream • gi.A.s g2.A.s 

We say gi = g^ holds iff both gi ^ g^ and (72 ^ 5i hold. 
We define two trivial interval predicates 

True. A. s S true 
False. A. s = false 

Like Interval Temporal Logic [37], for an interval predicate g, we say (□g).A.s holds iff g holds in each 
subinterval of A in stream s, say {<>g).A.s holds iff g holds in some subinterval of A, and say prev.^.A.s 
holds iff there is some immediately preceding interval of A within which g holds in s. More formally, we 
define: 

{ng).A.s = VA': Intv A' <ZA^ g.A'.s 
{<>g).A.s S 3A': Intv A' C A A g. A'. s 
prev.g.A.s = 3A' • A' cx A A g.A' .s 
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The chop operator ';' is a basic operator, where {gi ; (72) -A holds iff either interval A may be split 
into two parts so that gi holds in the first and 52 holds in the second, or the least upper bound of A is 
00 and gi holds in A. Thus, we define 

(ffi; 52).A.s = (3Ai,A2:/ntw(A = AiUA2) A(AiCxA2) A.gi.Ai.sA52-A2.s) V 
(lub.A = 00 A 5i.A.s) 

Note that Ai may be empty in which case A2 = A. and similarly if A2 is empty then Ai = A. In the 
definition of chop, we allow the second disjunct lub.A = 00 A (71. A to allow for 171 to model an infinite 
(divergent or non-terminating) program. 

We define the possibly infinite iteration of an interval predicate p as follows. We assume that interval 
predicates are ordered using universal implication and that the stream and interval are implicit on 
both sides of the definition. 

g'^ = i^z • {g ; z) V Empty 

Thus, (7" is a greatest fixed point that defines either finite or infinite iteration of g [24] . 

Properties that hold over a larger interval may be decomposed into properties of the subintervals if 
the interval predicate that formalises the property splits and/or joins [571 [22] ■ We also find it useful to 
reason about properties that widen, where a property holds over a larger interval if it holds over any 
subinterval. 

Definition 4.2 (Splits, Joins, Widens). Suppose g is an interval predicate. We say 

• g splits iS g ^ Og^ i.e., a g holds over an interval A, then g must hold over all subintervals of A, 

• g joins iff (g ; g") ^ g, i.e., for any interval A if 5 iterates over A, then g must hold in A, and 

• g widens iS Og ^ g, i.e., if 5 holds over some subinterval of A, then g holds over the interval A. 

4.4 Evaluating state predicates over intervals 

The values of an expression e at the left and right ends of an interval A with respect to a stream s are 
given by ^.A.s and l^^.A.s, respectively, which arc defined as 

V.A.s S e?;ffl/.e.(s.(glb.A)) 
l^.A.s ^ em/. e.(s. (lub.A)) 

Note that V.A.s is undefined if gib. A = —00 and l^.A.s is undefined if inf .A. Similarly, we use the 
following notation to denote that c holds at the beginning and end of the given interval A with respect 
to a stream s, respectively. 

V.A.s = gib. A ^ {-00,00} A c.(s. (gib. A)) 
~t.A.s = lub.A ^ {-00, 00} A c.(s. (lub.A)) 

It is often useful to specify that a state predicate holds on a point interval. Hence we define 

\c].A.s S 3t:Time- A = {t} A c.{s.t) 

Two useful operators for evaluating state predicates over an interval are He and <J>c, which ensure 
that c holds in all and some state of the given stream within the given interval, respectively. Thus, for 
an interval A and stream s, we define: 

(□c).A.s S Vt:A'c.(s.i) 
(Oc).A.s S 3t:A' c.{s.t) 

As demonstrated using Example 14.31 below, operator <$> may be used to give a straightforward for- 
malisation of the ABA problem. 
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Example 4.3 (The ABA problem). To effectively implement CAS-based operations, where CAS(ae, a, f3) 
is executed by a process p, operations are often structured so that the value at address ae is stored as 
value of variable a, some processing is performed on a and the result stored in a variable /3. Then a 
CAS(ae, a, j3) is executed to attempt updating the value at ae to /3. If the CAS fails, then the environment 
must have modified the value at ae since it was last read as a. However, it is possible for a CAS to succeed 
(when it should have failed) if the environment exhibits so-called ABA- like behaviour [S] , where the value 
at ae changes from say a to /3 and then back to a. ABA-like behaviour of an expression e is formalised 
using the following interval predicate: 

ABA.e = 3ki,k2 e Val' h ^ k2 A {<$>{e = ki) ; <>>{e = k2) ; (^-ie ^ ki)) 

Hence (ABA.e). A holds iff A can be partitioned into three adjoining intervals Ai, A2 and A3 such that 
the value at e is fci sometime within Ai, then changes to ^2 sometime within A2 and back to ki sometime 
within A3. Note that ABA.e allows the value of e to change several times when changing from ki to ^2 
then to fci . ^ 

We say a location va is stable at time t in stream s (denoted stable— at. va.t.s) iff the value of va in s 
at time t does not change from its value at time < — 1, i.e., 

stable— at. V a. t.s = s.t.va = s.{t — l).va 

Variable va is stable over an interval A in a stream s (denoted stable. ua. A. s) iff the value of va is stable 
at each time within A. A set of locations VA is stable in A (denoted stable. IM.A) iff each variable in VA 
is stable in A. Thus, we define: 

stable.ua. A. s = Vi: A • stable_at.ua. i.s 
stable. Vyl. A = Vm: • stable.ua. A 

Note that every location is stable in an empty interval and the empty set of locations is stable in any 
interval, i.e., both (stable. Fj4).0 and stable. 0. A hold trivially. 

4.5 Read/write permissions and interference 

As we shall see in Section [5. 1[ the behaviour a process executing a command is formalised by an interval 
predicate, and the behaviour of a parallel execution over an interval is given by the conjunction of 
these behaviours over the same interval. Because the state-spaces of the two processes are potentially 
overlapping, there is a possibility that a process writing to a variable conflicts with a read or write to the 
same variable by another process. To ensure that such conflicts do not take place, we follow Boyland's 
idea of mapping variables to a fractional permission j3j, which is rational number between and 1. A 
process has write-only access to a variable v if its permission to access w is 1, has read-only access to v if 
its permission to access v is above but below 1, and has no access to v if its permission to access v is 0. 
Note that we restrict access so that a process may not have both read and write permission to a variable. 
Because a permission is a rational number, read access to a variable may be split arbitrarily (including 
inflnitely) among the processes of the system. However, at most one process may have write permission 
to a variable in any given state. Note that the precise value of the read permission is not important, i.e., 
there is no notion of priority among processes based on the values of their read permissions. 

We assume that every state contains a permission variable H whose value in state a G Statey is a 
function of type 

V Proc ^ {n: Q I < n < 1} 

Note that it is possible for permissions to be distributed differently within states a, a' even if the 
values of the standard variables in cr and a' are identical, i.e., it is possible to get cr.H ^ cr.H' even if 
({H} ^ cr) = ({n} <g cr') holds, where denotes the domain anti-restriction. 

Definition 4.3 (Permission). A process p G Proc has write-permission to variable va in state a iff 
a.H.va.p ~ 1, has read-permission to va in cr iff < a.Il.va.p < 1, and has no-permission to access va in 
(7 iff a.n.va.p = holds. 
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We introduce the following shorthands, which define state predicates for a process p to have read-only 
and write-only permissions to a variable ua, and to be denied permission to access va. 

TZ.va.p = < H.va.p < 1 W.va.p = Yl.va.p = 1 D.va.p = H.va.p = 

In the context of a stream s, for any time t £ "L, process p may only write to and read from va in the 
transition step from s.{t — 1) to s.t if W.va.p and TZ.va.p^ respectively. Thus, W.va.p does not grant 
process p permission to write to va in the transition from s.t to s.{t + 1) (and similarly TZ.va.p). 

It is straightforward to use fractional permissions to characterise interference within a set of processes. 
For P C Proc and VA C Var U Addr, we define 

I.VA.P = 3va:VA,p:Proc\P' W.va.p 

which states that there may be interference on locations in VA from a process different from those in 
P. We use I.VA.p to denote I.VA.{p} for a singleton set {p} and I.va.P to denote I.{va}.P for a 
singleton set {m}. This characterisation of interference is particularly useful in this paper where we use 
rely conditions (see Section l7.ll) to formalise the behaviour of the environment. For example, to state 
that environment of p does not modify a variable w, we simply ensure that the rely condition implies 
H-iI.ii.p. 

Such notions are particularly useful because we aim to develop rely /guarantee-style reasoning, where 
we use rely conditions to characterise the behaviour of the environment. To state an assumption that 
there is no interference on va during the execution of a command that uses va, one may introduce 
{I]-CL.va.p as a rely condition to the command (see Example 17. ip . 

We define some conditions on streams using fractional permissions that formalise our underlying 
assumptions on access permissions. 

HCl If no process has write access to va G Var U Addr within an interval, then the value of va does not 
change within the interval, i.e., 

[r\{ip: Proc .va.p) stable. m 



HC2 The sum of the permissions of the processes on any location va is at most 1, i.e., 

□ ((SpgProcII.m.p) < 1) 



For the rest of this paper, we implicitly assume that these conditions hold. Alternatively, one could make 
the conditions explicit by adding them to the rely conditions of the programs under consideration. 

Using these healthiness conditions, we obtain a number of relationships between the values of a variable 
and the permissions that a process has to access the variable. For example, we may prove that if a process 
has read permission to a variable, then no process has write permission to the variable. Furthermore, if 
over an interval no process has write permission to a variable, then the variable must be stable over the 
interval. 

Lemma 1. Both of the following hold for any location va £ Var U Addr 

[Ii{{3p: Proc ' TZ.va.p) => (ip: Proc ' ^W.va.p)) (11) 
[I](yx: Proc ->W.va.p) ^ stable. -ya (12) 

One may also define additional properties. For instance, a set of locations VA may be declared to be 
local within a set of set of processes P using the following interval predicate. 



Local. VA.P = Vva-.VA'IH 



f {Vq:Proc\P'V.va.q) A 

\i(ip: P • -^W.v.p) {\fp: P ' TZ.v.p)) 



Hence, if Local. VA.P, then no process outside of P has permission to accesss the locations in VA and 
furthermore, if no process in P has write permission to a location va in VA, then all processes in P 
automatically obtain read permission to va. 

It is important to be able to determine the set of all variables and addresses that must be accessed in 
order to evaluate an expression in a given state. The set of variables that are accessed is state dependent 
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because an expression may involve pointers and the address that the pointer points to may vary with 
the state. Hence, we define a function accessed, which returns the set of locations (i.e., variables and 
addresses) accessed. Below, we assume that k G Va/, v G Var, a G Addr, f G Field, t G Time, ei, and 
62 are expressions and s is a stream. 

accessed. k. a = {} accessed. (ae-f). a ^ accessed. ae. a 

accessed. V. a = {v} accessed. {(Be). a = accessed. e. a 

accessed. {*ae). a = {eval. ae. a} U accessed. ae.cr accessed. (ei ® 62). cr S accessed. ei. cr U 

accessed. e2.cr 

We define the following predicate, which states that process p has permission to read each of the 
locations required to evaluate expression e in state a. 

ReadAllLocs.e.p.a Vva: accessed. e. a • TZ.va.p 

The following interval predicates state that process p writes to a location of e within interval A, that 
there is no interference on e within A, and that all other processes are denied access to the locations in 
e. 

{WriteSomeLoc.e.p).A.s = <^{3va* va G accessed. e A W.va.p) 
{IntFree.e.p).A.s ^ □(Vwa* va G accessed. e =^ —CL.va.p) 
{OnlyAccessedBy.e.p).A.s = □(Vwa • \/q: Proc\{p} • va G accessed. e =J> "D.va.q) 

5 Interval-based semantics of parallel programs 

In Section l5.ll we present our interval-based semantics of the programming model, and in Section [5. 21 we 
present the concept of enforced properties, which enable a behaviour of a command to be constrained. 
We present a theory for refining program behaviour in Section [5731 

5.1 Semantics of commands 

We use the following interval predicates to formalise the semantics of the commands in Definition 14.11 
where p is a process, va G Var U Addr is a location and Z C Var U Addr is a set of locations, e is an 
expression, k a constant and c is a state predicate. 

Vwa: Z • {H-iW.va.p 
<J>(e ^ k A ReadAllLocs.e.p) A idlep.2 

j\d\ep z\{va} A -lEmpty A □(wa = k A Wp.va) if va G Var 

\'\d\ep z\{va} A -lEmpty A □((* va) ~ k A Wp.va) if va G Addr 

Hence, idlep^^ states that process p docs not write to any of the locations in Z within the given interval. 
Interval predicate evalp_^(e, k) models the evaluation of expression e to a value k by process p in context 
Z, where evalp.z(e, k).A.s holds iff there is a state s.t (for t G A) such that the value of e in state s.t is k 
and p can read each of the locations needed to evaluate e in s.t. Furthermore, p does not write to any of 
the variables of the context Z within A. Interval predicate update^ zi^^^i ^) models the modification of 
location va to value k by process p executing in a context Z , where update^, ^(wa, k).A.s holds iff within 
s, throughout A, the value of va is k, p has write permission to va and does not have write permission 
to any other variable in Z. Additionally, ^Empty holds to ensure that va is actually updated — this is 
necessary because He trivially holds for an empty interval. 

We obtain the following lemma, which relates write permissions to expression evaluation and stability 
of a variable. 

Lemma 2. Suppose V , Z C_ Var, p G Proc, e is an expression and k G Val is a constant. Then each of 
the following hold: 

\d\ep^z ; e\/a\p^z{e,k) ^ evalp^^(e,fc) (13) 
evalp,z(e, fc) ; idlep,z ^ evalp,^(e,fc) (14) 



idlep,^ = 
evalp^z(e,fc) = 

updatepz{'va,k) S 
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&e/ip_^. Chaos = True behp^z-iCi ; C2) = behp_z-Ci ; behp^z-C2 

beh.p,z-\d\e = idlsp.z 6e/ip. ^. (Ci fl C2) = behp^z-CiW behp^z-C2 

behp^z-[c] = eva\.p^z-{c,true) behp^z-C'^ = {behp^z-CY 

behp^z-{^^YT c C) = prev. 1^ A behp,z-C behp^z-{l-C) = B{pcp = I) A behp^z-C 

behp^z ■{'V ■= e) = 3k ' e\/a\p,z{e, k) ; updatep z{v,k) 
behp^z -{ae :— e) = a • evalp_^(ae, a) A evalp^^(e, A;) ; update^ ^I'Jj ^) 

fTrue if P = 

fte/ip.z.C^P ifi' = {p} 

3Pi, P2 • (i^i U P2 = -P) A (Pi n P2 = 0) A otherwise 
behp,.zMp:P, Cp) ; Idle) A behp,,zMp:P^ Cp) ; Idle) 
behp,z\Y/C\ = Local.P.Y A (Z n Y ^ 0) A behp,zuY-C 



behp.z.{L,p Cp] 



Figure 6: Formalisation of behaviour function 



Definition 5.1 (Behaviour). The behaviour of a command C given by the abstract syntax in Defini- 
tion 14.11 executed by a non-empty set of processes P in a context Z C Var U Addr is given by interval 
predicate behp^z-C, which is defined inductively in Fig. |6l 

Within behp z the context Z defines the set of locations that the processes in P may or may not 
modify. For example, command Idle executed by process p in a context Z should not write to the 
locations in Z . Similarly, an assignment v := e should not write to locations in Z\{v}. 

In the description below, we assume that the executing process is p and the command under consid- 
eration occurs within the scope of a context Z . The behaviour of command Idle states that p does not 
write to any of the locations in Z . The behaviour of [c] states that c evaluates to true in some state 
within the interval, that process p has permission to read the locations of c in this state and, and that 
p does not write to any of the locations in Z. For example, within ToCAS{p) (Fig. [5|), [ptr.tp ^ null] 
holds iff there is a state in which p can read tp and the value of ptr.tp is non-null. 

Execution of a variable assignment v :~ e consists of two parts, where the value of e is evaluated to k, 
and then the value of v is updated to k. The executing process must have permission to read the locations 
of e within during the evaluation, and must have permission to write to v during the update. Note that 
because we assume true concurrency, the evaluation is non-deterministic (in the sense of [181 128| ). For 
example, consider the assignment tp *Top within ToCAS{p) (Fig. [5]). It is possible for *Top to change 
multiple times within the interval in which *Top is evaluated due to the execution of other processes. 
The value returned by the evaluation of * Top depends on the time at which the value at Top is read. 
Because tp is local to p, the update to tp may always be executed. Assignment ae := e is similar to a 
variable assignment, but the command must additionally must evaluate the address- valued expression ae 
to determine the address to be updated. 

The behaviours of sequential composition, non-deterministic assignment and iteration arc modelled 
in a straightforward manner using chop, disjunction and iteration of interval predicates. The parallel 
composition is chaotic if the given set of processes is empty and behaves as a single process if the set of 
processes is singleton. Otherwise the given set processes is partitioned into two disjoint subsets and the 
behaviours of both subsets occur in the given interval. Note that the two or more parallel processes may 
access the same shared variables — the manner in which these variables are accessed is controlled using 
fractional permissions. We allow Idle to be executed within the parallel composition to allow asynchronous 
termination [18| . 

The behaviour of | F / C | is the behaviour of C in an extended context Y no other process is given 
permission to access locations in Y during the execution of C. The behaviour of a labelled command 
assumes the existence of an auxiliary program counter variable pcp local to each process p. Execution of 
I: C by process p guarantees that pCp has value / throughout the interval of execution. Unlike [i m fTS l fTS l 
117] where labels strictly correspond to the atomic portions of the programs under consideration, we only 
use labels to determine auxiliary information and the same label may correspond to a number of atomic 
steps. 
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5.2 Enforced conditions 



We introduce a construct for defining an enforced condition, which restricts the behaviour of a command 
so that the property being enforced is guaranteed to hold |17j . 

Definition 5.2 (Enforced condition). For interval predicate d and command C, we let Enf d • C denote 
a command with an enforced condition d, where 



Hence, Enf c? • C executes as C and in addition guarantees that d holds [T71IH]- Note that if -id 
holds, then Enf d • C has no behaviours. Enforced conditions may be used to state properties of an 
implementation that may not be easily expressible as a command. We present three examples relevant 
to the Treiber stack to illustrate the use of enforced properties. Although each of the examples only 
uses enforced properties on fractional permissions, the theory of enforced properties is more general as it 
allows any interval predicate to be enforced [521 HIl HH] ■ 

Example 5.1 (Comparc-and-swap). A CAS(ae,a,/?) is atomic on ae, i.e., the value at address ae is 
guaranteed not to be modified by the environment over the interval in which CAS(ae,a, /3) is executed. 
Enforced properties, state predicate evaluation and fractional permissions are used together to formalise 
the behaviour of a CAS(ae, a, (3) executed by a process p, as follows: 



Note that due to the enforced properties OnlyAccessedBy.ae.p within CASOKp, the environment is denied 
access to the locations needed to evaluate ae. Although the CAS may take a number of atomic steps to 
execute, access to the test and set of ae occurs without any process accessing the locations in ae. A CAS 
that performs the test and set in a single transition may be considered to be an implementation of this 
specification. 

Because the CAS may take multiple steps, it is possible for the values of a and /3 to change. To 
achieve more deterministic behaviour over the interval, (in the sense of [28]), a and /3 are typically local 
variables of the executing process, and hence, by HC4, a and /3 cannot be modified by the environment 
of p. A CAS that performs a test and set in a single transition typically places further restrictions on 
the structure of ae to ensure implementability. jf, 

Example 5.2 (New nodes). We assume that the set of free addresses is given by FAddr. To ensure that 
two different processes arc not assigned the same free address, we must ensure that there is no interference 
to FAddr while p accesses FAddr. This may be achieved via an enforced condition on FAddr. 

newNode{p,v) = Enf OnlyAccessedBy. FAddr. p ' 

ri/neFAddr [Z*^ + offset.nxt £ FAddr] ; v := fn ; FAddr :— FAddr\{fn, fn + offset. nxt} 

Hence, newNode{p^ v) ensures that all processes different from q are denied access to the current set of 
free nodes FAddr. Furthermore, it non-deterministically chooses a free node from fn such that /n + 1 is 
a free node, then assigns fn to v, and removes both fn and fn + offset.nxt (i.e., fn and fn + 1) from the 
set of available free locations. JH 

Example 5.3. To further illustrate the use of permissions and enforced properties, consider the program 
in Fig. [71 which extends the abstract program in Fig. U] by allowing the operations to be executed 
concurrently by the processes in P C Proc. However, due to the enforced permissions, each process is 
guaranteed to update the stack without interference. Lynch |35j refers to such a program as a canonical 
specification of the concurrent stack. Note that some idling must be allowed both before and after the 
main operation to enable interleaving to take place. Without this idling, ii p ^ q, we have: 

behp^[s}-^P'ush{p, x) A behq is}-^P'ush{q, y) 
^ definitions 

<^TZ.S.p A OnlyAccessedBy.S.q 
= definitions 

false 



behp^z-i^^F d • C) 



d A behp z-C 



CAS0Kp{ae,a,l3) 
CASFailp{ae, a) 
CASp{ae, a, (3) 



Enf OnlyAccessedBy.{*ae).p ' [*ae = a] ] ae := /? 
[*ae ^ a] 

CAS0Kp{ae,a,(3) n CASFailp{ae, a) 
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APush{p, x) 

AEmpty{p, arvp) 
ADoPop(p, arVp) 
APop{p, arVp) 

APP{p) 

AS{P) 



Enf OnlyAccessedBy.S .p • SPush{x) 

Enf OnlyAccessedBy.S .p • SEmpty{arVp) 
Enf OnlyAccessedBy.S .p • SPop{arVp) 
AEmpty(p, arVp) □ APop{p, arVp) 

Idle; {{V\x:Vai APush{p,x))n APop{p,arVp)) ; Idle 
I^/INIT S = {)' W^.p larVp/APP{prjj 



- IntFree.S .p - 



Figure 7: A canonical stack specification 

- IntFree.S .p 

S-^W.S.q 



A„ 



A„ 



- IntFree.S .q- 



aW.S.q 



A„ 



- IntFree.S .q- 



□ W.5.g 



Figure 8: Conflicting execution - interfer- 
ence freedom with two writes 



Figure 9: Interference freedom with a read and 
write 



5.3 Behaviour refinement 

We prove correctness of the concurrent data structure by proving refinement between the concurrent 
program and an abstract specification and a concrete representation (e.g., in Section l673l we show LS{P) 
is a data refinement of AS{P)). The sets of locations of the abstract program may differ from those of 
the concrete program. Thus, we define a refinement relation between commands parametrised by the sets 
of abstract and concrete locations and the processes executing the command. 

We first consider behaviour refinement — a simple form a refinement in which the concrete and 
abstract state spaced do not need to be linked. 

Definition 5.3 (Behaviour refinement). Suppose A and C are commands in contexts (sets of locations) 
Y and respectively. We say A is behaviour refined by C with respect to a set of processes P (denoted 
A Cp'^ C) iff behp^z-C ^ behp^y-A holds. 

We write A C^'^ C for A ^^p^ C (i.e., the set of processes is the singleton set p), write for A Cp C 

for A Cp"^ C (i.e., the concrete and abstract contexts are identical) and write A Cp C for A Cp C (i.e., 
the abstract and concrete contexts are empty). Because refinement is defined by universal implication 
between behaviours, the following monotonicity results may be proved in a straightforward manner using 
monotonicity of the corresponding interval predicate operators. 

Example 5.4. The set of variables of the abstract program is given by: 

M = S\J {arVp \ p: P] 

We perform a behaviour refinement, where we show that the OnlyAccessedBy permission in Fig.[7]may be 
weakened to IntFree as given in program BS{P) in Fig. llOi i.e., we prove AS{P) g^f BS{P). Condition 
BS{P) AS{P) is trivial because OnlyAccessedBy.S .p => Intfree.S.p. Condition BS{P) \zf AS{P). 
holds because for any processes p, q G P such that p ^ q and intervals Ap, A, such that Ap n Ag 7^ 
(i.e., Ap and A, overlap), we have 

behp^s ■{BDoPush{p, arVp) □ BDoPop{p, arVp)).Ap ^ -ibehq s ■{BDoPush{q^ arvq) □ BDoPop{q, arVq)).Aq 

A visualisation of this is given in Fig. |8l where the write of process p conflicts with the IntFree.S .q 
condition in process q. Note that AEmpty{p, arvp) = B Empty (p, arvp)^ i.e., one cannot replace the 
enforced property OnlyAccessedBy .S .p by IntFree.S .p because for example 

behp^s .(Enf IntFree.S .p ' SEmpty{p, arVp)).Ap A behq^s-BDoPop{q, arVq).Aq 
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BPush{p,x) S Enf IntFree.S .p ' SPush{x) 

B Empty (p, arvp) = l^NF OnlyAccessedBy.S .p ' SEmpty{arVp) 
BDoPop{p, arvp) = Enf IntFree.S .p ' SPop{arVp) 
BPop{p, arvp) = BEmpty{p, arvp) □ BPop{p, arvp) 

BPP{p) = Idle; ((□:,: va( BPush{p,x))nBPop{p,arVp))] Idle 

BS{P) = I^/INIT S={)' W^.p larVp/BPP{pr\\ 

Figure 10: An equivalent specification to Fig. [7] 

is an allowable behaviour. This may be visualised as shown in Fig. [9l where condition IntFree.S.q in 
process q does not conflict with the execution of process q. Replacement of AS{P) by BS{P) simplifies 
the rest of the proof because the conditions that the implementation needs to ensure are weaker. 

Lemma 3. Suppose P is a non-empty set of processes, Y , Z C_ Var U Addr, and A, Ai, A2, C , C'l and 

A Y Z A Y Z A Y Z 

C2 are commands such that A IZp' C, Ai IZp' Ci and A2 Cp' C2 hold, and h and g are interval 
predicates. Each of the following holds provided that h' =^ b, Vfc: Val ' <$>{e' = k) ^ <J>(e = k) and h^ g. 

(15) 
(16) 
(17) 
(18) 
(19) 
(20) 

Using an interval-based semantics to formalise a program's behaviour allows one to obtain the following 
useful results which allows one to split a command executed over a large interval into subintervals, and 
combine a command executed over a number of adjoining intervals into the same command over the 
larger interval. 

Lemma 4. For any non-empty set of processes P and a command C, if behp.C joins, then both of the 
following hold. 

C ^p-^ C; C (21) 





[b] 


^Y,Z 


[b'] 


V 


:= e 


^Y,Z 


V := e' 


Ai 


; A2 


^Y^Z 
!=P 


Ci ; C2 


Ai 


n A2 


^Y.Z 
!=P 


Ci n C2 






^Y.Z 
!=P 




Init 


g'A 


^Y,Z 
!=P 


Init h • C 



C Cp'^ C; (22) 



-p 

-Y 
-P 

Lemma 5. For any non-empty set of processes P and a command C , if behp.C splits, then. 

C; C cj'^ C (23) 

Note that Cp' C holds trivially by the definition of The following lemma states that a guard 
evaluation is equivalent to a program that performs some finite length idling, some non-empty idling in 
which c is guaranteed to hold, followed by some more idling. 

Lemma 6. [c] (Enf Fin • Idle) ; (Enf(Hc A -lEmpty A ReadAllLocs.c.p) • Idle) ; Idle 

Note that the behaviours of both Enf Fin • Idle and Idle hold in any empty interval, and hence each 
of the properties below follow from Lemma [51 

[c] U^ (Enf(Hc a -.Empty A ReadAllLocs.c.p) • Idle) ; Idle (24) 
[c] Qp (Enf Fin • Idle) ; (Enf (Hc A ^Empty A ReadAllLocs.c.p) • Idle) (25) 
[c] ^p Enf(Hc a -.Empty A ReadAllLocs.c.p) • Idle (26) 

For example, Lemma [3] and Lemma [6] may be used to prove the following: 

[b] ^J^' [b] ; [c] (27) 

The lemma below allows refinement within a wider context. 
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Lemma 7. If A cjuy,Jfuz y CZ, WnY = = XnZ and W C X thenlW/A] C^'^ |^/C|. 

Proof. behp^z-lX/Cj 
= behaviour definition 

Local. Z.p A Z n X = A behp^zux ■ C 
^ assumptions 

Local. Y.p A W n Y = A behp^yuw-A 
= behaviour definition 

behp^Y-lW/Aj a 

We also obtain properties for refinement of enforced conditions. The lemma below states that a 
refinement may be performed by introducing a new enforced condition or by strengthening an existing 
enforced condition [TT l fTO l l ^ . 

Lemma 8. If C is a command, g and h are interval predicates, P is a set of processes and Y , Z are 
sets of locations, then both of the following hold. 

C Cp'^ Enf5'C (28) 
h^g => ENFff' C Cp'^ Enf/i' C (29) 

The lemma below allows decomposition within sequential choice and iteration, provided that the 
interval predicate under consideration joins. 

Lemma 9. // C, Ci and C2 are commands, g is an interval predicate that joins, Y , Z are sets of 
locations and P is a set of processes, then 

{Enf g ' Ci ; C2) ^p'^ (Enf 5 • Ci) ; (Enf 5 • C2) 
(Enf^'C") Cp'^ (Enf5'C)" 

The following lemma allows decomposition of behaviours with enforced properties over parallel com- 
position, sequential composition and non-deterministic choice. Note that decomposition over sequential 
composition requires that the interval predicate under consideration splits. 

Lemma 10. If A = \\p;pAp, C = \\p:pCp, Ai, A2, Ci, and C2 are commands, Y,Z C Var U Addr and 
g and h are interval predicates such that h splits, then both of the following hold. 

{\fp:P'Ap^^^^{ENFg'Cp)) ^ ^ Cp (Enf .g • C) (30) 
(^1 ^p-^ (Enf h'Ci)) a {A2 Cp (Enf h ' C2)) ^ {Ai ; A2 Cp (Enf h-d; C2)) (31) 
(^1 ^p'^ (Enf g • Ci)) A {A2 Cp'^ (Enf g • C2)) ^ {Ai n A2 Cp'^ (Enf 5 • Ci n C2)) (32) 

6 A coarse-grained linearisable abstraction 

In this section, we develop the coarse-grained abstraction of the Trieber stack (Section [OJ and develop 
interval-based data refinement rules (Section 16. 2p . In Section 16.31 we prove that the coarse-grained 
abstraction is linearisable with respect to the canonical stack specification from Fig. [7] via data refinement 
and in Section WM we discuss the importance of proving linearisability of coarse-grained abstractions. 

6.1 The abstraction LS{P) 

The coarse-grained abstraction (see Fig. [TT|) uses Top to obtain a pointer to the top of the stack. In 
addition, each process uses local variables rip and rvp for the new node to be inserted (by the push) and 
the value to be returned (by the pop), respectively. The stack addresses SAddr are defined to be the set 
of addresses that are reachable from Top. Hence, for a state cr, we define the following: 

ptr.{a. Top) 

j null if eval.{itern.cr ^ nxt).a = null 

\eval.{itern.cr 1— >■ nxt).a otherwise 

{node G Addr \ 3?i:N« node S {eval. {iter n- key). ct, eval .{itern ■ nxt) .a}} 



iterQ.a = 
itern+i-cr = 
SAddr.a = 
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EnvSt[p) = ¥^\^F^WriteSomeLoc.{SAddryj {Top}).p'Jrue 

LSetup{p,x) = newNode{np) ; (np-key) := x 

LDoPush{p) = Enf IntFree.{SAddr U {Top, Up-key, np-nxt}).p' 

{up-nxt) := ptr.[*Top) ; Top :~ (up, ctr.{*Top) + 1) 

LPush{p,x) S LSetup{p,x); EnvSt{p) \ LDoPush{p) 
LEmpty{p, rVp) = [ptr.{*Top) ~ null] ; rVp Empty 

LDoPop{p, rVp) = Enf IntFree.{SAddr U {Top}), p ' {[ptr.('¥ Top) ^ null] ; rVp := ptr.[*Top) t-^ key ; 

Top := {ptr.{*Top) t— > nxt, ctr.{*Top) + 1)) 

LPop{p,rVp) EnvSt{p) ; {LEmpty{p, rVp) Fl LDoPop{p, rVp)) 

LPP{p) = Idle; {\~\^.y^i LPush{p, x)) H LPop{p, arvp) ; Idle 
LS{P) = lTop,FAddr/lmTTInit- \\p.plnp,rVp/LPP{p)'^jl 

Figure 11: A coarse-grained abstraction LS{P) of the Treiber Stack 

Hence, SAddr.a denotes the addresses that are reachable from Top. 

Within program LS{p) in Fig.[TTJ each process p iteratively chooses executes LPP{p), which at each 
iteration performs some idling, then for a non-deterministically chosen value x executes LPush{p, x) 
or LPop{p, rVp), and then performs some more idling. Within LPush{p,x), command LSetup{p,x) 
initialises the push and EnvSt[p) allows some execution that does not modify the stack, and LDoPush(p) 
performs the actual push. The coarse-grained pop is modelled by LPop{p), which allows some initial 
(non-interfering) idling, then either behaves as L Empty (p, rVp), which models a coarse-grained pop on 
an empty stack, or LDoPop{p, rvp), which models a coarse-grained pop that removes the top element of 
a non-empty stack. 

Like many CAS-bascd implementations, Trciber's stack may retry its main operation a number of 
times before succeeding. An abstraction of this behaviour is modelled by the command EnvSt(p), which 
guarantees that none of the addresses corresponding to the stack have been modified. 

For the rest of this paper, we assume that the set of variables of the coarse-grained abstraction is 
given by L, which is defined as follows. 

L = { Top} U FAddr u[j{np,rvp} 

p:P 

Example 6.1. One can prove that the addresses in SAddr (i.e., those corresponding to the stack) are 
not modified by LS{P). In particular one may prove 

behp^L-LS{P) ^ Mp-.P'^WriteSomeLoc.SAddr.p (33) 
6.2 Data refinement 

It is possible to prove behaviour refinement between the coarse-grained program LS{P) and the fine- 
grained implementation TS{P). However, it is not immediately obvious that LS{P) is linearisable. It 
turns out that a linearisability proof of LS{P) is non-trivial, however, the proof is simplified because 
large portion of the code are executed atomically. 

As shown by Doherty et al [5l[T5l[T4] and again by Derrick et al [42l[12l[T5, a sound method for proving 
linearisability is to verify data refinement from an abstract representation of the data structure being 
implemented to the concrete program. Using the framework of input / output automata |34| , Doherty |14j 
constructs a so-called canonical automata in which each operation executes by invoking the operation, 
then executes an (internal) atomic step (corresponding a step of the data type being implemented) and 
then returns to an idle state. The argument made is that every trace of the canonical automata is a 
linearisable |141 [Sj [15] and hence any refinement of this automata must also be linearisable. However, 
because this claim is not formally verified. Derrick et al present an extension that allows links data 
refinement to the Herlihy and Wing's original definition [42l [El [12] . In this paper, we apply this extended 
method to an interval-based setting that allows true concurrency. 
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An abstract program A is simulated by concrete program C with respect to a simulation predicate 
sim if the initialisation of C together with sim implies the initialisation of A and any behaviour of C over 
an interval in which sim holds implies the behaviour of A^ and additionally sim holds throughout that 
interval. For streams si and S2, we define 

Si lyj S2 ^ t- Time • Si.t U S2.t 

If the state spaces corresponding to si and S2 sltc disjoint, then for each t e Time, (si lyj S2).t is a state 
and hence Si P S2 is a stream. 

Definition 6.1 (Data refinement). Suppose P C Proc, Y, Z Var U Addr are locations such that 
Y n Z = 0, AInit e StatePredy, and CInit e StatePredz- We say A = \Y /imi AInit ' Al is data 
refined by C = |Z/lNlT CInit • C J with respect to a simulation predicate sim G StatePredyuz iff both: 

VfTa: Statey , cTc- Statez ' CInit. aa A sim.{<7a U (Tc) =^ AInit. aa (34) 
Vsci Streamz, A: Interval, a: Statey • 

sim.{a U Sc.(glb.A - 1)) A behp,z-C.A.Sc ^ (35) 
3sa: Streamy • {a = Sa.(glb.A — 1)) A □sim.A.(sa P Sc) A &e/ip^y.^.A.Sa 

This establishes a data refinement [5] between the abstract program A and concrete program C 
in interval-based setting, where the programs execute in parallel in a truly concurrent manner. As in 
traditional data refinement, our definition relies on a refinement relation sim which links the concrete and 
abstract states. Condition (p4|) ensures that every initialisation of the concrete program that is related 
to an abstract state via sim must imply an initialisation of the abstract program. By (|35p. for every 
concrete stream Sc, interval A and abstract state a, provided that both 

1. sim holds between a and the state of Sc just before A and 

2. the concrete program executes in s^. over A 
then there exists an abstract stream Sa such that 

1. the state of Sa that immediately precedes A is cr, 

2. sim holds in the combined stream Sa W Sa throughout A, and 

3. the abstract program executes in over A. 

Proving condition ([55]) directly is difficult because it does not decompose. However, a predicate of 
the form p =► {3x • g A r) holds if both p ^ 3x ' q and Va; • p A g => r hold. Hence, psp can be proved 
by showing that both of the following hold. 

Vsci Streamz, A: Interval, a: Statey • (36) 
sim. {a U Sc-(glb.A - 1)) A behp,z -C .A.Sc => 

3sa: Streamy • (cr = .Sa.(glb.A - 1)) A Bsim.A.{sa P Sc) 

Vsci Streamz, A: Interval, Sa'. Streamy • (37) 
□ .sim.A.(.Sa lyj Sc) A behp^z-C.A.Sc => behp^y.A.A.Sa 

By (|36p . the simulation condition sim must be such that for any execution of the concrete program 
that executes from a state that satisfies sim, there must exist an abstract stream such that sim holds 
throughout the interval. To simplify representation of intervals of the form in p6p . we introduce the 
following notation. 

(5 linky c).A.5 = Vct: S'iaiey c.(crU s.(glb.A - 1)) A ,g.A..s ^ 

3sy: Streamy • a = Sy.{g\h.A - 1) A Bc.A.{sy P s) 

g dref Y z c = Vszi Streamz, A: Interval • (g linky c).A.Sz 

By (j37|) for any concrete and abstract streams and interval, if the concrete program executes in 
the interval and forward simulation holds throughout the interval, then it must be possible to execute 
the abstract program in the interval and stream. Because Y n Z = 0, we may further simplify (j37]) to 
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□ sim A behp^z-C ^ behp^y-^, which may be written using behaviour refinement and enforced properties 
as 

A Cp'^ Enf Hsim'C (38) 

We prove this as follows: 
(EZl) 

Ynz = 

Wsc'. Streamz, A: Interval, Sa' Streamy • 

□ sim.A.(sQ lyj Sc) A behp^z-C.A.{sa P Sc) behp^y .A.A.{sa ^ Sc) 
= logic 

\/s: Streamyijz, A.: Interval' {Hsim. A. s A behp^z-C .A.s => behp^y .A.A.s 
= definition of and 'C' 

dMl) 

Condition (pH]) can also be decomposed. First, we prove the following lemma that allows one to 
decompose a proof of a simulation predicate over chop, which in turn enables decomposition of sequential 
composition. Similar proof techniques for relational frameworks are well studied [S] . 

Lemma 11. Suppose p G Proc, Y,Z C Var U Addr such that Y n Z = , gi,g2 G IntvPredz and 
c G StatePredyijz ■ Then {{gi ; 32) dref c) holds if both (gi drefy^z c) and (g2 dref y,^ c) hold. 

Proof. For an arbitrarily chosen a G Statey, A G Interval and G Streamz, we have the following 
calculation. 

c.{a U .s,.(glb.A - 1)) A (gi ; g2).A.s, 
~ definition of ';' 

c.(cr U s^.(glb.A - 1)) A {3Ai,A2: Interval' (Ai U A2 = A) A (Ai a A2) A gi.Aj A g2.A2.s^) 
=^ logic and gIb.Ai = gib. A 

3Ai,A2: Interval' {Ai U A2 = A) A (Ai a A2) A c.(<t U .s^.(glb.A - 1)) A ^i.Ai.s^ A g2.A2.5z) 

use (gi dref y^^ c) and logic 
3Ai, A2: Interval, Sy-. Streamy • (Ai U A2 = A) A (Ai a A2) A 

a = Sy.(glb.Ai - 1) A n]c.Ai.{sy W s^) A g2.A2.Sz 
= use □c.Ai.(sy ILi) Sz), Ai a A2 

3Ai, A2: Interval, Sy-. Streamy • (Ai U A2 = A) A (Ai a A2) A 

a = Sy.(glb.Ai - 1) A □c.Ai.(sy lyj s^,) A 

{3a': Statey • c.(cr' U s^.Cglb.Aa - 1))) A g2.A2.Sz 

=J> logic and (32 dref y^^ c) 

3Ai, A2: Interval, Sy, s'y-. Streamy, a': Statey • (Ai U A2 = A) A (Ai oc A2) A 

cr ^ Sy.{g\h.Ai - 1) A □c.Ai.(sy y s^) A 
a' = 4.(glb.A2 - 1) A □c.A2.(4 P s.) 
=^ can pick s^' G Streamy such that Vt: Ai • Sy.t = Sy.t and Vt: A2 ' Sy.t = s'y.t, 
then rename Sy to Sy 
3Ai, A2: Interval, Sy-. Streamy, a': Statey • (Ai U A2 = A) A (Ai a A2) A 

a = Sy.(glb.Ai - 1) A □c.Ai.(sj, Itl) s^) A 
a' = s,^.(glb.A2 - 1) A □c.A2.(Sy P s^) 

=^ logic, He joins, and gIb.Ai = gib. A 

3sy: Streamy ' a = Sy.(glb.A — 1) A □c.A.(sy lyj s^) □ 

We use the following lemma to further decompose proof obligation ([36]). 

Lemma 12. If Y , Z <Z Var such that Y n Z = , g E IntvPredz , Sz G Streamz and A G Interval. Then 
{g linky c).A.Sz holds holds if there exists a w G StatePredz such that: 

g.A.Sz =► linky c).A.Sz A □(□-•w linky c).A.Sz (39) 

Proof. For an arbitrarily chosen cr G Statey , A G Interval and G Streamz and prefix A' of A, we have 
that either Hw.A'.s^ or El-iw.A'.Sz holds. By we have that and a similar calculation to the proof 
of Lemma [TlJ □ 
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start_recordp(t;, e) 
end_recordp('y, e) 

ARecord(Inv, Res) 
L Record {Inv , Res) 

HAPush{p, x) 

H A Empty {p, arvp) 
HADoPop{p, arVp) 
HAPop{p, arVp) 

HAPP{p, arVp) 
HAS(P) 

HLPush{p, x) 
HLEmpty{p, rvp) 
HLDoPop{p, rVp) 

HLPP{p) 
HLS{P) 



3k • prev.e = 1 A v = k A W.v.p 
3k' e = k; \{v = k) A W.v.p'] 
er\d_recordp{HA, HA ^ {Inv, Res)) 

start_recordp{HL, HL {Inv)) A end_recordp(ffl, HL ^ (Res)) 

Enf A Record {pushp{x), pushp) • BPush{p, x) 

Knf A Record {popp, popp{arVp)) • BEmpty{p, arVp) 
Enf ARecord{popp, popp{arVp)) • BPop{p, arVp) 
HAEmpty{p, arVp) □ HADoPop{p, arVp) 

Idle; {{r\^.,vai HAPush{p,x))n HAPop{p,arVp)) ; Idle 

[5/lNiT^ = (). Wp.p HAPP{p)^\ 

Enf LRecord{pushp{x),pushp) • LPush{p, x) 
Enf LRecord{popp, popp{rVp)) • LEmpty{p, rVp) 
Enf LRecord{popp, popp (rVp)) • LDoPop{p, rVp) 

Idle ; ((n^: vai HLPush{p, x)) n HLPop(p, rVp)) ; Idle 
{Top.FAddr/lmT TInit' \\ p. pfup, rVp / HLPP{p)'^ jj 



Figure 12: Programs BS{P) and LS{P) extended with history, status and labels 



cc 


null 






X 


14 




0,0, 


Y 


bb 


Z 


Z 


Z + 1 


Top 


X 


X + 1 


Y 


Y + 1 



Figure 13: A state corresponding to abstract stack (aa, bb, cc)., where ptr.{*Top) ~ X and ctr.{*Top) = 
14 

6.3 Linearisability of LS{P) via simulation 

Derrick et al show that a proof of linearisabihty can be reduced to a proof of data refinement by encoding 
the definition of linearisability from Section [2.2! within the simulation relation and extending the abstract 
and concrete programs with histories of invocations and responses [121 [13l |42] . Programs AS{P) and 
LS{P) extended with histories are respectively given by programs HAS{P) and HLS{P) in Fig. [121 In 
particular, the canonical program produces a sequential history by recording an invocation immediately 
followed by the matching response in history HA at the end of the executions of both HAPush{p, x) and 
HAPop{p, arVp). On the other hand, the coarse-grained atomic program LS{P) is extended to HLS{P) so 
that invocations and responses of HLPush{p, x) and HLPop{p, arVp) in history HL. Note that invocations 
and responses of operations of HLS{P) may not be sequential, i.e., other processes may be arbitrarily 
interleaved between any matching pair of events. 

In addition, one must also establish a relationship between concrete stack (represented as a linked 
list) and the abstract stack (represented as a sequence of values). Hence, for an concrete state a S StatcL, 
we define: 

^ size.SAddr.a . , „ , „ 
Stack. a = let /en = tn \n:0..len ~ !• [itern.Top ^ key).a 

Example 6.2. Consider the abstract stack corresponding to the state a depicted in Fig. [131 We have 



iterQ.a= ptr.{a.Top) 
= X 



iteri.a= eval.{iterQ.a nxt).a 

= eval.{*{X + offset.nxt)).a 
= eval.{*{X + l)).cr 

= (7.{X + 1) 

= Y 



Similarly, iter2.<7 = Z and iter^.a = null. Hence, Stack.a = {aa, bb, cc) 
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Theorem 6.1. HAS{P) is data refined by HLS{P) with respect to 

simTS S {S ^ Stack) A (Vp: P • W.S.p = W. Top.p) A lmeansable{HL, HA) (40) 

Condition (p8|) establishes a relationship between concrete stack (which is a linked list) and its abstract 
representation (which is a sequence), ensures that for any process p, the process has permission to write 
to S iff it has permission to write to location Top and that that the concrete history HC is linearisable 
with respect to the abstract history HA. 

The linearisation of push and a non-empty pop correspond to the intervals in which Top is modified, 
and the linearisation point of the empty pop corresponds to an interval in which ptr.{* Top) = null holds. 
Hence, we use ([^5)) to split the HLEnipty{p, rvp) operation into the before, during and after cases of the 
linearisation point as follows. 

HLEmptyPre{p, rVp) = Enf start_recordp(_ffL, HL ^ (popp)) A Fin • Idle 
HLEmptyLin{p,rVp) = Enf [I]{ptr.{* Top) ~ null) A ->Empty A TZ. Top.p ' \d\e 
HLEmptyPost{p, rVp) S 'ENFend_recordp{HL, HL^ {popp{rVp)}) • rVp := Empty 

To prove this, we first show the more straightforward property that for any process p and interval A 
in which p has write permission to Top throughout A, p maintains simTS throughout A. Furthermore, 
simTS is also maintained if no process writes to Top. 

Lemma 13. Both of the following hold: 

behp,L-HLS{P) ^ n{[i]{3p: P -W. Top.p) Wnku simTS) (41) 
behp^L-HLS{P) a{n](yp: P ' ^W. Top.p) Wnku simTS) (42) 

This holds because there is always a corresponding abstract stack after an update to Top and fur- 
thermore intervals in which Top is modified can be treated as linearisation intervals by appending corre- 
sponding invocation and response events to the abstract history. □ 

The only way to modify simTS is to write to HL and the only operations that modify HL without 
writing to Top are the invocations of each operation and the return operation HLEmptyPost{p, rvp). Ev- 
ery invocation is trivial because we may treat them as non-pending operations, and HLEmptyPost{p, rvp) 
is satisfied by treating operations that have executed HLEmptyLin{p, rVp) as a pending invocation. □ 

We now return to the proof of the theorem that establishes data refinement between HLS{P) and 
HAS{P). 

Theorem \6.1\ The proof of the initialisation condition p4p is trivial. The main condition psp is proved 
by first splitting the proof into conditions (pS)) and ([57)1 . To prove ([M]) . i.e., 

behpx.HLS{P) drefM.L simTS 

we apply Lemma [T^ with w instantiated to 3p: P • W. Top.p and use (PT|) and (|42p . We must now prove 
([37|. which we have shown above holds by ((38)) . i.e., 

HAS(P) Cp'^ E^iF[nsimTS' HLS{P) 

Using Lemma [To] (i.e., decomposition of parallel composition) and Lemma |3] (i.e., monotonicity of", this 
may be proved by showing that for any p £ P . 

HAPP{p) C^^^ ENFBsimTS- HLPP{p) 

Because Idle Qp' Idle ; Idle, we may further decompose this using Lemma [101 where the non-idle cases 
are given below, and the rest of the HAPP{p) arc refinements of Idle 

HAPush{p,x) C^'-^ Enf BsimTS ' LDoPush{p) 
HAEmpty{p, arvp simTS • HLEmptyLin{p , rVp) 

HADoPop{p, arVp) C^"^ Enf □simTS' • HLDoPop{p, rVp) 

Each of these proofs is straightforward due to assumption [H simTS. □ 
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6.4 Remark: The importance of proving linearisability 



It is also worth noting that some abstractions of the Treiber Stack cannot be Hnearised, which reinforces 
the importance of proving hnearisabihty of a coarse-grained abstraction, as opposed to methods such as 
[45j , which only prove refinement between a concurrent data structure and its coarse-grained abstraction 
without showing that the abstraction itself is linearisable. 

Example 6.3. A pop abstraction 

[ptr.{*Top) =/= null] ; 

Enf H-iI. Top.p • rVp :~ ptr.{* Top) H- key ; 

Top := {ptr.{*Top) i— > nxt^ ctr.{*Top) + 1) 

cannot be proved linearisable because it is possible for Top to change after the ptr.[*Top) ^ null holds 
within the guard evaluation [ptr.{*Top) ^ null]. Hence, for example, when Top is updated, the stack 
may already be empty. JH 

Example 6.4. It is not necessary to strengthen LEmpty{p) to 

Enf H-iI. Top. p • [ptr.{*Top) = null] ; rVp := Empty 

because the value of Top is never used in the latter parts of the code. The guard [ptr.{*Top) = null] is 
merely used to decide whether or not the code should return. Although this strengthening docs provide 
one with a coarse-grained program that is linearisable, the proof that the coarse-grained program is 
implemented by the Treiber Stack TS{P) will be more difficult to achieve. ^ 



7 Compositional proofs 

In this section, we describe how the proof of a command may be decomposed into proofs of the subcompo- 
nents. In particular, we present rely conditions in Scction Fy.ll and decomposition Section [7. 2 1 over parallel 
composition using rely conditions. In Section [7. 3[ we present a number of high-level transformation rules 
specific to CAS-bascd implementations. 

7.1 Rely conditions 

We introduce constructs for defining a rely condition, which specifies assumptions about the behaviour of 
the environment [3T]. We note that unlike Jones [3T], who assumes rely conditions are relations, we rely 
conditions are interval predicates, allowing specification of properties over an interval. The behaviour of 
a command with a rely condition is given by the behaviour of the command in an interval in which the 
rely condition is assumed to hold. That is, the behaviours of the environment overlap [18] with those of 
the program as opposed to interleave |3H 141] with the program. 

Definition 7.1. For an interval predicate r and command C, we let (Relyt* C) denote a command 
with a rely condition r, whose behaviour for any set of processes P and set of locations Z C Var U Addr 
is given by 

behp -(Rely r • C) = r ^ behp,z-C 

Hence, (Rely r'C) consists of an execution of C under the assumption that r holds. Note that if 
-ir holds, then the behaviour of (RELYr* C) is chaotic, i.e., any behaviour is allowed. 

This interpretation of rcly/guarantce has been shown to be effective for reasoning in a real-time setting, 
where conflicting updates by a program and its environment arc avoided by ensuring the environment 
variables are disjoint from the program variables |211 122] . In this paper, a program and its environment 
may share a common set of locations, hence we use fractional permission to ensure conflicting accesses 
do not occur. 

Example 7.1. Suppose we want show that for an assignment x := x -\- 1, the final value of x is one 
greater than its initial value provided that the environment does not modify x. We have 
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behp^z -{Rely [H^I.x.p • x := x + 1) 
= definition of beh 

\r\-CL.x.p 3k • behp^z-[x + I = k] ; updatep^^(a; ~ k) 
^ He splits 

\r\-CL.x.p => 3k • {[H^I.x.p behp^z-[x + I = k]) ; update^ 2(2^ ^) 
^ using m^I.x.p and by definition behp^z-[x + 1 ^ k] ^ \I\-iW.x.p 
B^I.x.p ^ 3k • □(2; + 1 = A;) A -lEmpty ; b{x ^ k) A -lEmpty 

EE^ He V 

B^I.x.p =^3k'x + l = kA -lEmpty A x ~ I 
^ logic 



B^T.x.p ^ 3k' X — k A -lEmpty A x ^ k + 1 # 
7.2 Decomposition using rely conditions 

One may develop a number of rules for refining commands with rely conditions. 
Lemma 14. Each of the following holds. 

Rely r • C □ J'^ C (43) 

r' =^ Rely r • C Cp Rely r' • C (44) 

r A behp.C ^ behp.A Rely r • ^ Cp'^ Rely r • C (45) 

rAbehp.C^d => Rely r • Enf d • C Cp'^ Rely r • C (46) 



Rule (US]) allows a rely condition to be removed, (|33]) allows a rely condition to be weakened and by 
, the refinement holds for the rely condition r on both sides if the behaviour of C implies the behaviour 
of A under rely condition r. By (j46p . we may remove the enforced property d if the rely condition and 
behaviour of C together imply d. Of course, it may be the case that only the rely condition without the 
program or the program without the rely condition is enough to establish the enforced property. Both 
these cases are covered by (|46|). 

The lemma below allows one to distribute a rely condition in and out of a sequential composition and 
an iterated command. The lemma requires that the given rely condition splits. 

Lemma 15. Suppose r is an interval predicate, P a non-empty set of processes and Y , Z are sets of 



variables. If r splits, then 

(Rely r • Ci ; C2) Ep (Rely r • Ci) ; (Rely r • C2) (47) 

Rely r'C"^ Cp'^ (Rely r'C)" (48) 

{RELYr ' AHp'^ C) ^ (Relyt'^" Cp-^ C") (49) 



The following theorem shows that rely and enforced conditions form a Galois connection. Namely, 
command C refines a command A under rely condition r if and only if the command C with enforced 
condition r refines A. 

Theorem 7.1. (Rely r • A) Ep C = ^ Ep (Enf r • C) 

Proof (Rely r • A) □ J'^ C 

~ definitions and logic 

r A behp^z-C ^ behp^y-A 
= definitions 

^ Cp'^ (ENFr* C) □ 

To see the usefulness of this theorem, consider the lemma below that allows refinement over non- 
deterministic choice in the presence of a rely condition. Using Theorem 17.11 and the result of Lemma [16] 
(below), we obtain a dual result ([50]) below on an enforced property. 

Lemma 16. ((Relyt'^i) Cp'^ Ci) A ((Rely ^2) ^p'^ => (Rely r • ^1 n ^2) Ep'^ Ci n C2 
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Using ThGorcm l7.11 the results (|28p and Lemnia[T6]may both immediately be converted into a property 
for enforced conditions: 

One can also use Theorem 17. II and Lemma [15] to obtain the following dual property, where we assume 
g is an interval predicate that splits. 

(ENF3' Ci) ; (Enf^' C2) Cp'^ (Enf g • Ci ; C2) (51) 

The following theorem may be used to decompose a proof that an parallel composition of an abstract 
program is refined by the parallel composition of a concrete program in the context of an overall rely 
condition r. 

Theorem 7.2. (Rely r • W^.p Ap) Ep-^ (jj^.p Cp) holds if there exist Pi,P2 C _P such that P = P1UP2 
and Pi n P2 = and both of the following hold for some interval predicates ri and r2 . 

{RELYr An- \\ p., p^Ap) {lp..p,Cp,) (52) 

(RELYr Ar2.||,^P,^p) C^^^ %..P,Cp,) (53) 

r hhehp^^z.{\\p.,p,,Cp) ^ n (54) 

r M)ehp^,z.{\\p,p^Cp) ^ r2 (55) 

Proof dSH) A (E 



— definition of ^J'^, logic (a ^ (& ^ c)) = (a A & ^ c) 
(r A n A hehp,,z.{\\p,.,p^ Cp) ^ behp.^y .{\\p.,p^ Ap)) A 
(r A r2 A hehp^^z -{Wp-.p^ Cp) ^ behp^^y .{\\p.,p^ Ap)) 
=> logic 

r A ri A hehp.^z -{Wp-.p, Cp) A ra A behp,_,z .{\\p,p^_ Cp) hehp.^y -{Wp-.p, Ap) A hehp^^y .{\\^.p^ Ap) 
=> dSll) and ^ 

r A hehp,^z-{\\p.,p^ Cp) A behp^^z.{\\p.,p.^ Cp) ^ hehp.^y .{\\^.p^ Ap) A hehp.,^y .{\\^.p^ Ap) 

Hence we have the following calculation: 

3^1, F2 • -Pi U f2 = A (Fi n ^2 = 0) A dSll) A (USD 
=> calculation above and logic 

P2 • {Pi U P2 = F) A (Pi n P2 = 0) A r A hehp,^z-{\\p.,p^ Cp) A behp.^z ■{\\p,p,_ Cp) ^ 

^<ihPuY-{\\p.,p^ Ap) A behp.-^ y .{\\ p Ap) 

= definitions 

(RELVr- llp^P^p) Cp (llp^p Cp) □ 

When modelling a lock- free program [8l [131 El] : one assumes that each process repeatedly executes 
operations of the data structure, and hence the processes of the system only differ in terms of the process 
ids. For such programs, a proof of the parallel composition may be simplified to as described by the 
theorem below. 

Theorem 7.3. Suppose p G Proc and A and C are commands with input parameter p such that W Y 
and X C Z. Then (Rely r • \\p.p A{p)) Cp (lip p C{p)) holds if the following holds for some interval 
predicate ri and some p E P where Q = P\{p}. 

(Rely r An- A{p)lZ J '"^ C{p)) A (r A behg.iW^.Q Ciq)) ^ n) (56) 

Proof. Applying Theorem 17.21 and choosing Pi = {p}, and P2 = Q, the proof of 

(RELYr.||p^P^(p))c;-^(||p^p(7(p)) 

decomposes as follows for some interval predicates ri and r2. 

(RELYrAri.^(p)Cp^^^ (7(p)) A {Rely r A r2 ' \\p,Q A{p) C{p)) (57) 

(rAbehg.iW QCip))^ri) A {r A behp.C{p) ^ r2) (58) 
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The first conjuncts of conditions (|57|) and (|58|) hold by assumption (|56p . Choosing r2 = true, the proof 
of the second conjunct of ((58|) is trivial and the proof of the second conjunct of (|57)) follows by induction 
on the size of the set of processes Q. In particular, wc use the fact that the behaviour of Wp.^ ^{p) is 
true as the base case of the induction. □ 



7.3 Transformation rules 

In this section wc present a number of additional refinement rules that allow one to transform coarse- 
grained code into code with finer granularity. These proofs arc greatly simplified by the fact that we 
consider interval-based behaviour, which includes consideration of the possible interference from other 
processes. The theorems we present arc developed around the Trcibcr Stack example. Wc anticipate 
that several more can be developed when considering other examples. Wc further conjecture that such 
theorems can also be used to derive concurrent data structures via a series of refinements. 

The theorem below allows refinement of an enforced property {I]{e = va) to a command C within 
Rely r • va := e ; C ; [e = va] provided that C does not write to va and the rely condition r ensures 
that the ABA problem does not occur on e. 

Theorem 7.4. Suppose p is a process, Z C VarUAddr, v £ ZCl Var, e is an expression, C is a command 
and r is an interval predicate. If both of the following hold 

behp^z-C ^ S^W.v.p (59) 
r ^ a^ABA.e A {Wq:Proc\{p}'^W.v.q) (60) 

then 

Rely r • V -.^ e ; (Enf □(£ = u) • C) ; [e = v] v := e ; C ; [e = v] (61) 

Proof. Condition (pT|) is equivalent to 

r f\ hehp^z-{v '■= e ; C ; [e = v]) ^ hehp^z -{v :— e ; (Enf □(£ = w) • C) ; [e — v]) 
By logic, the antecedent of the formula above is equivalent to 

r A behp^z-iv ■= e ; (Enf (□(£ = u) V 0(e ^ v)) • C) ; [e = v]) 
The □(e = v) case is trivial. For the <^(e ^ v) case, we have 

r A hehp^z-{v e ; (Enf 0(e ^ v)' C); [e = v]) 
^ (IMl) and ([601) together implies Vg: P • H^W.-y.g 

r A behp,z-{v := e ; (Enf (^(e ^ v) A stable. u) • C) ; [e = v]) 
EE^ dSni), behp^z-[e ^ v] ^ B^W.v.p and HCl 

r A behp,z-{v e ; (Enf (^(e 7^ n) A stable.-y) • C) ; (Enf stable. w • [e = w])) 
^ behp z definition 

r A 3fc« 0(e = k) ; (□(« ^ k) A -.Empty) ; (0(e 7^ v) A stable. w) ; (stable.?; A 0(e v)) 
^ using stability of v 

r A3k' ^{e ^ k) ; (□(« = A;) A -.Empty) ; 0{e ^ k) ; <^{e = k) 
^ using r -lABA.e 

false □ 

The theorem below allows one to replace an assignment to an expression by an equivalent assignment 
provided that the process under consideration has the necessary permissions. 

Theorem 7.5 (Replace assignment). Suppose e and e' are expressions, v E Var, Y C_ Z C (VarUAddr) 
are sets of locations and p is a process. If IntFree.e.p A 6e/ip.z.ldle ^ ReadAllLocs.e.p, then 

RELYH(e = e') A IntFree.e.p' w := e EJ'^ v := e 

Proof. The proof holds if □(€ = e') A IntFree.e.p A behp^z-{v '■— e') ^ behp^y-iv := e) 
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□ (e = e') A IntFree.e.p A behp^z-iv '■— e') 
= definition of behp^z 

□ (e = e') A IntFree.e.p A 3k • 
= definition of eval 

□ (e = e') A IntFree.e.p A 3fc • (0(e' = A; A ReadAllLocs.e' .p) A &e/ip_^.ldle) ; updatep_^(?;, fc) 
^ using 0(6 = e') and assumption IntFree.e A &e/ip^^.ldle ^ ReadAllLocs.e.p 

3k ' {<$'{e = k A ReadAllLocs.e.p) A 6e/ip_2.ldle) ; updaiBp zi'iJ^ ^) 
^ ^ -^j definition of behp^y 

behp^Y-iv ■= e) □ 

The following theorem allows one to split a guard evaluation so that the variable being tested is stored 
locally. The theorem allows one to perform some additional behaviour that does not affect the abstract 
state. 

Theorem 7.6 (Introduce command). Suppose e is an expression, v is a variable, ae is an address-valued 
expression, p is a process, Y , Z C_ Var such that both Y C Z and v E Y , and C is a command. Then 
both of the following hold: 

V := e Qp'^ C ; v := e provided behp^z-C ^ idlep^y (62) 

ae e ^p'^ C ; ae e provided behp^z-C ^ idlep^y A -^WriteSomeLoc.ae.p (63) 

Proof. We prove as follows. The proof of (|63p follows the same structure. 



behp^z-{C ; v := e) 
= definition of behp z 

behp z-C; 3/; • evalp_z(e, fc) ; updatep^(?;, fc) 
^ assumption on hehp,z.C 

idlep^y ; 3fc • evalp_2(e, fc) ; update^ ^(''j ^) 
EE> logic, Y (1 Z and v E Y 

3fc'idlep_y; evalp^y(e, fc) ; update^ y (u, fc) 
^ (|13p and definition of behp y 

behp^Y-{v e) □ 

Guard and expression evaluation occur in two different (observable) states, and hence, for example, 
[a = 42] ] V :~ a does not guarantee that v has a final value 42 because the value of a may change after 
the guard evaluation. The following theorem shows that testing a guard can be split over multiple steps 
by introducing a new local variable to the program. 

Theorem 7.7 (Split guard). Suppose va, v E Z , k is a constant and behp^z-C idleyujuaj then 

[v ~ k] Cjf'^ va :^ v ; Enf IntFree.va.p • [C ; [va ~ k\) 
Proof. We first prove the following: 

IntFree.va.p A (behp z-C ; evalp^^(?;a, fc)) 
^ assumptions behp^z-C ^ idleyy|,„Q-j. and Y (1 Z 
stable. ?;a A (idlep^y ; evalp^y (ua, fc)) 
(HSl) 

stable. iifl A evalp,y(?;ffl, k) 
^ use stable. iifl 
E\{va = k) A idlep^y 

Then, we have the following calculation 

behp z-{va := v ; Enf IntFree.va.p ' (C ; [va — k])) 
^ expand definition 

{3j • eya\p,z{v,j) ; updatBp ziva,j j) ; {IntFree.va.p A {behp ^z -C ; e\/a\p^z{'va, k))) 
^ calculation above 
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{3j • e\/a\p,z{vj) ; update^ zi^aj)) ; = A;) A idlep,y 

^ logic, assume j fresh 

3j ' eva\p,z{v,j) ; updatep^^(wa,j) ; □(wa = fc) A idlep^y 
^ case analysis on j = fc, case j ^ k yields a contradiction 

eMa\,p^z{v-,k) ; updatSp ^(?;ffl, A;) ; idlcp^y 
^ ^ ^, definition of update using assumption va ^ Y 

evalp, y (u, A;) ; idlsp^y ; idlcp.y 
^ ([H)) twice and definition of &e/i 

behp Y-[v ~ k] □ 

A theorem such as Theorem 1 7. 71 is more difficult to establish in a model that only considers pre/post 
states because the guard evaluation on the left of E^''^ is over a single state and the command on the 
right is over multiple states. 

The following theorem allows an assignment to be introduced provided that the new variable is distinct 
from the abstract context. 

Theorem 7.8. Suppose Y, Z C Var such that Y C Z, v ^ Z\Y and e is an expression and p 6 Proc. 
Then 

ENF-iEmpty Idle C^'^ v := e 

Proof. The refinement holds because v ^ Y^ Y C Z and v :~ e ensures idle2\{«}. □ 

We also develop a transformation theorem for executing a successful CAS operation. 

Theorem 7.9 (Introduce CAS). Suppose ae is an address-valued expression, e is an expression, a ^ Z 
and r is an interval predicate such that 

r ^ {Ii{accessed ae) C Z) A IntFree.a A (64) 
□ ((*ae = a) ^ (/3 = ae K^/)) (65) 
[^{ReadAllLocs.p.a ReadAllLocs.e) (66) 

Then 

RELYr'ae:=:e CASOKp{ae,a, (3) 

Proof. Using Theorem 17. li we may equivalently prove ae := e Cp Enft* CASOKp{ae,a, (3). We have 
the following calculation. 

6e/ip,z.(ENF r • CASOKp{ae, a, /?)) 
= expand definitions 

r A IntFree.ae.p A (6e/ip^^.[*ae ~ a] ; behp^z-{ae /3)) 
= expand definitions 

r A OnlyAccessedBy.{*ae).p A 

(evalp_^.(*ae — a, true) ; 3a, k • (evalp.z(ae, a) A evalp^z(/3, k)) ; updatep^^(a, k)) 
^ logic, expand definitions 
r A OnlyAccessedBy.{*ae).p A 

3a, k • (<S>(*ae = a) A idlep,^) ; (evalp^z(ae, a) A eva\p^z{(3, k)) ; updatep^(a, k) 
r A OnlyAccessedBy.{*ae).p A 

3a, k • (<^(*ae = a) A evalp,^(ae, a) A evalp,^(/3, k)) ; updatGp ^(a, k) 
^ (|M)) . a G Z and OnlyAccessedBy.{*ae).p implies all locations in *ae = a are stable 
r A 3a, k • (□(*ae = a) A evalp_^(ae, a) A evalp^^(/3, k)) ; updatep_^(a, k) 

^ (EH) 

r A 3a, k • (□(/? = e) A evalp_^(ae, a) A evalp,z(/3, k)) ; updatep^^(a, k) 

□(/? = e) and §6\i 
r A3a,k' (evalp^z(ae, a) A evalp^zie, k)) ; updatep^^(a, k) 
^ definitions 

behp^z-{ae := e) □ 
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8 Behaviour refinement the Treiber Stack 



In this section, we verify that the Treiber Stack (modelled by TS{P)) refines the coarse-grained abstract 
program (modelled by LS{P)), i.e., we prove: 

LS{P) Cp TS{P) (67) 

Om- proof strategy decomposes the parallel composition (Section 18. ip . which allows us to consider the 
push and pop operations executed by a single process separately (Section 18.21 and Section l873|) . We derive 
the necessary rely conditions for the push and pop operations as part of the proofs in Sections 18.21 and 
18.31 which are then discharged in Section [5^ 



8.1 Decompose parallel composition 

We first apply Lemma [7] and then ([20]) of Lemma [3] to reduce the refinement to the following proof 
obligation: 

\\p:pLP{p) ^7 \UTP{p) (68) 

where 

TP S {Top,PAddr} 

LP{p) = lnp,rVp/LPP{prj 

TP{p) S |tp,«p,tep,™p/TFF(p)-] 

Using Theorem 17.21 we further decompose the parallel composition in ([55)1 to obtain the following proof 
obligations. 

n' lpp{pY pp{pT (69) 

behp,^TF-{\\p,PP{pY) ^ n (70) 

Condition ri is yet to be determined, and is calculated as part of the proof of (|69p . However, we 
require that the condition ri that we derive splits to allow our transformation lemmas to be applied. 
Recalling that the L denotes the set of variables of the coarse-grained abstraction LS{P), wc define 

T = LU {p: Proc tUp^rVp} (71) 

to be set of variables of the coarse-grained abstraction TS{P) and obtain the follows. 

dMl) 

decompose iteration assuming ri splits 



Rely n • LPP{p) cj^ PP{p) 

(|47|) of Lemma [T5l assuming ri splits, then Lemma [TBI 
Rely n • LPush{p) C^'^ Push{p) A (72) 
Rely n • LPop{p) C^- Pop{p) (73) 



8.2 Proof of push operation l \72\} 

We prove the Push{p) operation as follows: 

Rely n • LPush{p) C^'^ Push{p) 
<^ expand definitions 

YiEhY rx' LSetup{p^x) ] EnvSt{p) \ LDoPush{p) n^''^ Setup{p, x) ; TryPush{p)'^ ; DoPush{p) 
-4= Lemma [TSl assuming ri splits 

Rely n ' EnvSt{p) ; LDoPush{p) C^^^ TryPush{pY ; DoPush{p) 
<^ Lemmas [S] and m using EnvSt{p) both splits and joins 

REhY n' EnvSt{p)] EnvSt{p); LDoPush{p) C^^^ TryPush{pY ] DoPush{p) 

Using Lemma |15I (i.e.. monotonicity of ';') fmd the assumption that ri splits, the final refinement above 
holds if both of the following hold. 

YlEhY ri' EnvSt{p) E^^^^ TryPush{pY (74) 
Rely n ' EnvSt{p) ; LDoPush{p) n^-'^ DoPush{p) (75) 
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Proof of ([741). 

dm) 

Lemmas 2] and m as EnvSt{p) both joins and splits 

Rely n • EnvSt{pY □^^''^ TryPush{pY 

(Rely ri • EnvSt{p))'^ C^-^ TryPush{p)'^ 
<=^ Lu is monotonic 

Rely n • EnvSt{p) E^'^ TryPush{p) 
O Theorem 17.11 

EnvSt{p) Cp'^ ENFri' TryPush{p) 

Commands /13 and /i/g of TryPush{p) trivially satisfy the requirements on the write permissions within 
EnvSt{p), and hence satisfy EnvSt{p). For command /14, we must ensure that Up-nxt ^ SAddr, otherwise 
-iWriteSomeLoc.SAddr may not hold. Hence, we require that ri implies: 

□ (pcp = /14 => (up-nxt) ^ SAddr) (76) 

Using assumption ([75)1 . the proof of (|74p is completed. 

Proof of (|75p. By Theorem 1 7. 1[ we may turn any rely condition on the left of ^^'"^ into an enforced 
property on the right. Hence, condition (|75p is equivalent to: 

EnvSt{p); LDoPush{p) C^'^ n' DoPush{p) (77) 

To prove (|77p . we first simplify the right hand side of Cp'"^- Because Top includes a modification counter 
and every update to Top increments this counter, each new value of Top is guaranteed to be different 
from all previous values and hence, the following is trivially guaranteed: 

U^ABA.Top (78) 

We write C Ep' A for ^ Cp' C and perform the following calculation. 

Enf ri • DoPush{p) 
□J expand DoPush{p), remove labels 

Enf ri • tp := *Top ; Up-nxt := ptr.tp ; CASOKp{Top, tp, (up, ctr.tp + 1)) 
□J assumption (f78| and Theorem 17.41 

Enf ri • tp := *Top ; 

(Enf (□(-!!. Top. p A tp = *Top)) • Up-nxt :— ptr.tp) ; CASOKp{Top, tp, {up, ctr.tp + 1)) 

□ J Theorem O then (1211) of Lemma m 

Enf ri • tp := ^Tbp ; 

(Enf H-iI. Top. p • rip-nxt :— ptr.{*Top)) ; CASOKp{Top, tp, {rip, ctr.tp + 1)) 

□ J assumption ri splits, then (|5ip and Lemma [51 to remove enforced property 

(Enf ri • :=* Top) ; (79) 
(ENFri • (ENFB^I.Top.p' rip-nxt := ptr.{*Top)) ; CASOKp{Top, tp, {rip, ctr.tp + 1))) (80) 

Hence, by p?l) of Lemma [31 the proof of (|75l) holds if we prove both of the following: 

EnvSt{p) C^'^ (CH) (81) 
LDoPush{p) C^'^ (Uni) (82) 

The proof of ([HI) is trivial. For (|82p . we strengthen ri so that it implies that there is no interference on 
the stack nodes if there is no interference on Top and that there is no interference on addresses rip ■ key 
and rip-nxt, i.e., we require that ri satisfies: 

□ (□-iT.Top.p IntFree.SAddr.p) A IntFree.{np-key, rip-nxt}. p (83) 

Thus, we have the following calculation. 
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□J expand definitions 

Enf ri • (Enf H-iI. Top.p • Up ■ nxt :~ ptr.{* Top)) ; 

(Enf H-iJ. Top.p • [* Top tp] ; Top := (rip, ctr.tp + 1)) 
3 J He joins for any state predicate c and Lemma [5] 



-p 

Enf (ri A [Il-iX. Top.p) • Up-nxt := ptr.{*Top) ; [kToj; = tp] ; Top := (rip, ctr.tp + 1) 
3 J (|63|) of Theorem 17.61 and assumption (|83|1 

Enf IntFree.{SAddrU {Top, Up-key, Up-nxt}). p' (up-nxt) :~ ptr.{*Top) ; Top := 
(rip, ctr.{*Top) + 1) 

□J definition of LDoPush{p) 

LDoPush{p) 

8.3 Proof of pop operation ( 1731) 

We may decompose this operation as foUows: 

Rely n • LPop{p) Ep'^ Pop{p) 

<^ expand definitions 

RELYri • EnvSt{p) ; {LEmpty{p) U LDoPop{p)) C^'"^ TryPop{p)'^ ; {Empty{p) U DoPop{p)) 

-4= distribute EnvSt{p) spUts 

Rely n • EnvSt{p) C^-"^ TryPop{p)'^ A (84) 
Rely n • LEmpty{p) Cp'^ Empty {p) A (85) 
Rely n • EnvSt{p) ; LDoPop{p) C^'^ DoPop{p) (86) 

Proof of ()84p . This property holds in a similar manner to the proof of ([7^. In particular, the proof 
holds because TryPop{p) does not modify any location within {Top, Up-val} U SAddr. 

Proof of (|85p . This property is trivial using monotonicity properties and Theorem 17.71 

Proof of (|86p . We strengthen ri so that it implies 

□ (□(*Top = tp A pcp = /tr) □(top = ptr.{*Top) i-^ nxt) A IntFree. SAddr .p) (87) 

By (|87|) . if the global top value Top matches the local copy tp, then the global next value Top. nxt must 
be the same as the local copy tUp, and that there is no interference on the locations within SAddr. Using 
this condition, we prove (|86p as follows. 

Enf ri • ToCAS{p) ; Itr. CASOKp{Top, tp, {tup, ctr.tp + 1)) 
□J expandin definition of ToCAS{p) 

Enf ri • tp := *Top ; [ptr.tp ^ null] ; trip := ptr.tp H- nxt ; rwp := ptr.tp t-> fcey ; 
Itj: CASOKp{Top, tp, {tUp, ctr.tp + 1)) 
□J Theorem EH and ([751) 
Enf ri • tp := *Top ; 

^Enf(h-iT. Top.p A *Top — tp) • [ptr.tp ^ null] ; 

tUp := ptr.tp I— >■ nxt : 
rWp ptr.tp t— )■ A;ey 
/ty: CASOKp{Top, tp, {tUp, ctr.tp + 1)) 
□J use □(*Top = tp), then Lemma [5] 

behp^T-CASOKp{Top,a,l3) -^W.tp.p 
Enf ri • tp *Top ; 

^Enf H-iT. Top.p • [ptr.{*Top) ^ null] ; 

tUp := ptr.{*Top) H> nxt : 
rVp := ptr.{*Top) i— >■ key 
Itr. CASOKp{Top, tp, {tUp, ctr.{*Top) + 1)) 
3 J (EH) using ri splits, then weaken enforced property 



32 



tp := *Top ; 
Enf H^I. Top.p • [ptr.{* Top) ^ null] ; \ 
tnp :~ ptr.{*Top) i— > nxt ; ; 
rvp :— ptr.{*Top) i~> key J 
ENFri • Itr- CASOKp{Top, tp, {tUp, ctr.{*Top) + 1)) 
□J Theorem EH using (|87p . CASOKp{ae,a, 13) ^ IntFree.ae.p 
tp := *Top ; 

Enf H-iI. Top.p • [ptr.(=i! Top) ^ nuH] ; tep ptr.{*Top) i— > nxt ; rup :~ ptr.{*Top) n> A;ei/ ; 
Top := {ptr.{*Top) i— > ctr.{*Top) + 1) 

Using monotonicity of the proof of ([BS]) reduces to the fonowing proof obhgations. 

£^7it;5'fp C^'^ tp:=*Top (88) 
[p<r.(*Top) 7^ nw/Z] C^''^ [ptr.{*Top) ^ nu/Z] ; fnp := ptr.{*Top) ^ nxt (89) 

The proof of ([55]) is trivial because ip ^ T. Property ([55)1 holds as follows: 

[ptr.(*Top) 7^ nitZ/] 
Cp definitions 

[ptr.{*Top) ^ null] ; (Enf (-lEmpty) • Idle) 
□ p Theorem 17.81 because tnp ^ L 

[ptr.{*Top) 7^ null] ; irjp :~ ptr.{*Top) t— >■ mi 

8.4 Proof of d7D]) 

The rely condition ri is required to imply ((75)) . ([75]) and ([57)1 . We define the weakest possible condition 
and obtain 

n = dZSl) A dZS]) A dlZD 

To prove ((76)) . we show that the condition below holds: 

Vg: P\{p] • □(pc, = ht^ ^ Uq ^ Up) A □(pc^ = /i? ^ 7^ "p) 

which ensures that process q can never insert Up into the queue. The proof of the formula above relies 
on the fact that SAddr n FAddr = is an invariant of TS{P). Invariance of SAddr D FAddr = is 
straightforward to verify. 

To show that processes q ^ p satisfy (|87p. we must consider commands executed by process q that 
either make the antecedent true or falsify the consequent of (j87p . The counter for Top is only incremented 
and hence process q ^ p cannot make the antecedent of (j87p true. Furthermore, the command in process 
q that falsifies the consequent (i.e., CASOKq{Top, tq, {tn^, ctr.tq + 1))) also falsifies the antecedent. 

9 Conclusions and related work 

Methods for verifying linearisability have received a large amount of attention in the last few years. 
Herlihy and Wing's original paper use possibilities and Owicki/Gries-style [39] proof outlines, which 
defines the set of possible abstract data structures that corresponds to each point of interleaving. As 
we have already mentioned, Doherty et al [5l [15] use a simulation-based method using input /output 
automata, Vafeiadis et al use a framework that combines separation logic and rely/guarantee reasoning 
[ini HE] and Derrick et al have developed refinement-based methods [TTJ [T^J [13] • O'Hearn et al develop 
a method using a so-called hindsight lemma [55] and Jonsson presents a method that uses refinement 
calculus [22]. A number of tool-based methods have also been developed, but these often place restrictions 
on the final implementation. For instance, Amit et al present static analysis techniques [T], Burckhardt 
et al [4] develop a tool for checking whether or not an algorithm is deterministically linearisable (so 
that future behaviour need not be considered) and Vafeiadis has developed a tool that can be used to 
verify linearisability for such deterministically linearisable algorithms |47| . Verification of linearisability 
using coarse-grained abstraction has been proposed by Turon and Wand, but they do not show that the 



33 



abstraction itself is lincarisable |45] . Elmas et al [25] , and separately Groves [26] use a reduction-based 
method, but unlike our approach, these methods are not compositional. 

Despite this large set of results, due to the complexity of such concurrent data structures a satisfactory 
scalable solution to verification remains an open problem. The approach proposed by this paper is to 
split a verification into two phases — the first reduces the size (and hence complexity) of the problem 
by showing (via a series of small refinements) that the atomicity of an implementation can made more 
coarse, leaving one with a simpler program that can be verified to be linearisable. Note we have presented 
the verification in a different order, i.e., shown linearisability of the abstraction first. 

This paper presents a compositional interval-based method of verifying linearisability that does not 
require one to identify the linearisation points within the concrete code. Instead, we prove that the 
concrete code implements a coarse-grained abstraction. Due to this coarse granularity, the linearisation 
points are easier to identify and the proof itself is simpler. Rely/guarantee-style rules together with 
splits/joins properties are used to develop transformation theorems, which are in turn used to decompose 
proof obligations. By using an interval-based framework together with fractional permissions we are able 
to model true concurrency between parallel processes. This also enables reasoning at a finer level of 
atomicity than is often allowed because we allow reasoning at the level of variable and memory accesses 
during expression evaluation. 

As Baumler et al point out, reasoning over interval allows one to determine the future behaviour of 
a program, which in turn allows one to sometimes avoid backwards reasoning [2], e.g., the Michael and 
Scott queue |36| . Our experiments indicate that interval-based reasoning via coarse-grained abstraction 
also simplifies proofs of Heller et al's coarse grained lazy set algorithm [53], which is known to have 
linearisation points outside the operations being verified [JB] [HI [13] • In the terminology of Burckhardt et 
al, this corresponds to a non-deterministically linearisable program, and hence lies outside the scope of 
the tools in [Tl[4l[47]. We believe that interval-based reasoning allows generality beyond pre/post state 
reasoning, and that such generalisations are necessary for taming the increasing concurrency in everyday 
applications. 

The methods we have presented have not yet been mechanised and this remains the next obvious 
extension to this work. We conjecture that the refinement-based framework will also be useful for a 
derivation, which we aim to explore as part of future work. Such work would draw on, for instance, the 
derivational approach proposed by Vechev and Yahav [49] . 
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